Re: [Discuss-gnuradio] GR 3.4.2 sdcc issue...
On Thu, Jul 25, 2013 at 6:42 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: To get OpenBTS up and running together with the USRP1 I need gnuradio 3.4.2. These instructions here http://gnuradio.org/redmine/projects/gnuradio/wiki/UsingLibusrpWith3_5 are a good way to go, did this several times with (K)Ubuntu 12.04 LTS 32 bit. Now on a new machine I need to use Debian Jessie 64 bit, to get all the hardware support I need for the new PC. Latest gnradio 3.7 is no problem at all, but the above mentioned old version does not build. The configure command from the website stops after a while, complaining that no sdcc is available. In fact it is installed, but version 3.2, unlike the old system, where 2.9 is installed. Is this the reason for the issue, would installing 2.9 fix this? Then I would need to search the sdcc site how to do this :) I am not a Linux pro, so I avoid such stunts as long as possible... Try this gnuradio 3.4.2 branch. Make sure that at least volk and usrp2 are disabled (--disable-volk --disable-usrp2). It built on Fedora 18 a few days ago. https://github.com/ttsou/gnuradio.git fedora17 -TT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.7.0building problem on RHEL6.0
On Wed, Jul 24, 2013 at 10:00 AM, Nemanja Savic vlasi...@gmail.com wrote: today I tried installing 3.7.0 on my RHEL machine, but without success and with the following error message during make: [ 70%] Building CXX object gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/TimeDomainDisplayPlot.cc.o /home/savi_ne/tools/gnuradio-3.7.0/gr-qtgui/lib/TimeDomainDisplayPlot.cc: In member function ‘void TimeDomainDisplayPlot::setSemilogy(bool)’: /home/savi_ne/tools/gnuradio-3.7.0/gr-qtgui/lib/TimeDomainDisplayPlot.cc:358: error: ‘class QwtScaleDiv’ has no member named ‘upperBound’ Your qwt version is older than 5.2.0. Part of the QwtScaleDiv interface was changed between 5.1.1 and 5.2.0 - just a rename actually. lBound -- lowerBound hBound -- upperBound You can either update your version of qwt or rename the non-existent calls to the older interface. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on ARM
On Sat, Mar 23, 2013 at 5:36 PM, Sid Boyce g3...@blueyonder.co.uk wrote: I don't know if anyone has attempted it but I thought I'd have a go on Ubuntu 12.10 on an ODROID-X. Main problem it reports is a known bad version of boost that prohibits it building gnuradio-core and other components. I just compiled on Arndale (Cortex-A15) and Linaro 12.12 with the following options and cmake file. -DENABLE_BAD_BOOST=ON -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a15_native.cmake -TT 0001-cmake-add-toolchain-file-for-arm-cortex-a15-hard-flo.patch Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Raspberry Pi Activity?
On Thu, Jan 17, 2013 at 11:20 AM, Ed Criscuolo edward.l.criscu...@nasa.gov wrote: I thought it has an Arm11! From Wikipedia: The Raspberry Pi has a Broadcom BCM2835 system on a chip (SoC),[3] which includes an ARM1176JZF-S 700 MHz processor VideoCore IV GPU,[12] and originally shipped with 256 megabytes of RAM, later upgraded to 512MB. The architecture is ARM11 - the instruction set is ARMv6. ARM11 is an ARM architecture 32-bit RISC microprocessor family which introduced the ARMv6 architectural additions. These include SIMD media instructions, multiprocessor support and a new cache architecture. These would seem to imply that the R-Pi has SIMD instructions available. There are indeed SIMD instructions available for integer operations, and the Pi may be fairly capable in fixed point operation. For floating point, the VFPv2 coprocessor has a vector mode that speeds up certain operations, but still runs serially. From a DSP architecture standpoint, the floating point unit is dated and not particularly interesting. In addition, the VideoCore IV GPU looks like it's a pretty capable DSP in it's own, capable of running it's own applications without the CPU. Sounds like Volk could take advantage of it as well. Access issues aside, that is the way the Raspberry Pi should be used. The big, powerful GPU is the exciting part and there just happens to be a usable ARM processor attached on the side. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about OpenBTS
On Sun, Jun 3, 2012 at 9:49 AM, Pan, Luyuan panluy...@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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD with libusrp ?
On Wed, May 2, 2012 at 3:20 AM, Vanessa Quaranta vanessa251...@gmail.com wrote: transceiver: usrp_standard.cc:1024: virtual bool usrp_standard_tx::set_tx_freq(int, double): Assertion `dac_rate () == 12800' failed. 1335942873.3055 WARN 3078358736 TRXManager.cpp:254:sendCommandPacket: TRX link timeout on attempt 1 1335942873.3057 ALARM 3069520752 TRXManager.cpp:85:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1335942873.3057 ALARM 3069520752 TRXManager.cpp:85:clockHandler: TRX clock interface timed out, assuming TRX is dead. Abandon So, I think the problem is the clock! How can I patch GNURadio 3.6.0 or libusrp for that? With GNURadio 3.2.2 we need to patch files from /usrp/host/lib/legacy/* files but with the newer version, I don't know how to patch these files.. The 'TRX clock' error is slightly misleading and refers to the GSM frame / timeslot counter. It is mostly unrelated to 52 MHz clock that drives the hardware. The most common reason for TRX clock errors is that the transceiver fails to start - no device present, tuning fails, missing permissions, etc. To be clear, GNURadio is not required for OpenBTS operation. But, OpenBTS requires libusrp in order to use the USRP1, and libusrp is contained only in older versions of GNURadio. Version 3.4.2 was the last that contained libusrp. My suggestion for 52 MHz USRP1 operation with OpenBTS is the following configuration: openbts p2.8 gnuradio 3.4.2 (the last version with libusrp) No other USRP related packages are necessary and no code needs to be patched. While there are still some users that prefer version 2.6 derived versions because of the easier text file based configuration, I suggest version 2.8 because of better maintenance and support you will likely receive. Also, with libusrp no longer being supported by GNURadio, the OpenBTS mailing list may be a better place to ask questions. http://sourceforge.net/mail/?group_id=230904 Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] openLTE annoucement
On Wed, May 2, 2012 at 8:18 AM, Ben Wojtowicz bwojt...@gmail.com wrote: Thomas, Thanks for giving it a try!! If you get me your VZW recording, I can take a closer look to see what is going wrong with the SIB decoding. I'll try to post some captures by the end of the week. I should mention that I used some hacks to create the 30.72 Msps signal. I captured the 10 MHz signal at 12.5 and 25 Msps and resampled (in real time) with some test code linked to the OpenBTS transceiver. There were some limitations to keep the samples moving, and it's very possible that I mangled the signal in the process. I would like to pull a 40 Msps capture from test equipment (30.72 Msps is not an option), resample off-line, and try again. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] openLTE annoucement
On Sat, Apr 28, 2012 at 9:26 PM, Ben Wojtowicz bwojt...@gmail.com wrote: I am pleased to announce version 00.05 of openLTE, an open source LTE project (sourceforge.net/projects/openlte). This version includes a gnuradio application that reads recorded I/Q downlink LTE data from a file, decodes MIB and SIB1, and displays the decoded information. This is awesome. I pulled this from the local Verizon tower with a USRP2. DL LTE Channel found: Frequency Offset = -19.63 System Frame Number = 234 Physical Cell ID = 74 Number of TX Antennas = 2 Bandwidth (MHz) = 10 PHICH Duration= Normal PHICH Resource= 1 I wasn't able to decode the SIB. I have what appears to be a decent signal with a discone antenna near the window, but the CRC check on the DCI never clears. I'll play with it some more when I have some free time (unfortunately not in the near future). Really cool stuff though. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] digital_correlate_access_code_bb
On Sat, Apr 7, 2012 at 10:12 PM, Marcus D. Leech mle...@ripnet.com wrote:
Here's a little beauty of a code snippet:
d_access_code = 0;
for (unsigned i=0; i 64; i++){
d_access_code = 1;
if (i len)
d_access_code |= access_code[i] 1; // look at LSB only
}
The piece was committed almost 6 years ago - into CVS - and has not
changed since. Like many things, I'm sure it seemed like a much better
idea at the time.
Thomas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_spectrum_sense.py segmentation fault problem
On Tue, Dec 20, 2011 at 5:11 AM, Sebastian Döring sdoer...@rhrk.uni-kl.de wrote: -- #0 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 #1 0x0810ab61 in PyThread_release_lock (lock=0x0) at ../Python/thread_pthread.h:374 #2 0x080dbad3 in PyEval_ReleaseLock () at ../Python/ceval.c:262 #3 0x00fa6073 in gr_py_feval_dd::calleval(double) () This is likely a similar issue with the Python GIL (global interpreter lock) that occurred previously on the E100. In that case the final cause was a missing ctypes library. http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-June/001479.html To find out, try this thread hack. The patch is old, so you will probably need to apply manually against the current master. diff --git a/uhd_spectrum_sense_sum.py b/uhd_spectrum_sense_sum.py index 70f530f..31bf458 100644 --- a/uhd_spectrum_sense_sum.py +++ b/uhd_spectrum_sense_sum.py @@ -32,7 +32,11 @@ import sys import math import struct import time +import threading +class ThreadClass(threading.Thread): +def run(self): +return class tune(gr.feval_dd): @@ -306,6 +310,9 @@ def main_loop(tb): if __name__ == '__main__': +t = ThreadClass() +t.start() + tb = my_top_block() try: tb.start() # start executing flow graph in another thread... Thomas ___ 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 signals...@yeah.net: 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
Re: [Discuss-gnuradio] USRP purchasing recommendation
On Fri, Nov 4, 2011 at 6:08 AM, Martin Flasskamp mflassk...@cit-ec.uni-bielefeld.de wrote: Hello all, I want to set up a demonstrator system for wireless communication between two USRP devices. Some weeks ago, Matthias Wilhelm proposed the UCLA Zigbee implementation as a good starting point because of its complete and robust code. Now I reached the point that I want to buy two identical USRP devices for testing. Which platform is suitable to handle Zigbee and which platform will get the best support in the future? I think the USRP1 is outdated and there is no ongoing software development for this platform? That is not true. The USRP1 is supported by the UHD driver, which serves as common code base for all USRP products. UHD development is very active. FPGA specific development on the USRP1 has largely ceased, which is a concern for certain use cases, though not for the aforementioned ZigBee implementation. So, which one should I buy? N200 or E100 Series? Which Model? That depends on your specific objectives. What are your primary concerns? Lowest price? Largest Bandwidth? Embedded form factor? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A wrong power adapter connected to USRP and now it doesn't work (LED doesn't blink)
On Thu, Nov 3, 2011 at 12:15 PM, Marcus M gnu.f...@gmail.com wrote: My adviser accidentally plugged in a laptop's power adapter into a USRP for a few seconds and now it doesn't respond and GNU Radio doesn't detect it either after connecting to the laptop and testing it. What do I do? I hope that there must be a fuse that is replaceable or some sort of mechanism to prevent the USRP from being fried. Any help will be greatly appreciated. Do the LED's work? If not, check the fuse on F501. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_fft.py returns Segmentation fault
On Oct 28, 2011 11:57 PM, Josh Blum j...@ettus.com wrote: On 10/28/2011 12:20 PM, Vanessa Gardellin wrote: Please let me know if you solve the problem, I also have a seg fault... So help me help you... What version of gnuradio? What version of uhd? Do the uhd example apps work? Can you import the gnuradio python module? A similar, more detailed report was posted a few weeks ago. http://osdir.com/ml/discuss-gnuradio-gnu/2011-10/msg00227.html Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raw input data for those without hardware
On Sat, Aug 6, 2011 at 9:56 PM, Ben Reynwar b...@reynwar.net wrote: I'm wanting to have a play with gnuradio with some real data, rather than make-pretend software generated stuff, but don't have any particular transmission type in mind. I thought there were a couple of websites where people had uploaded some dumps of various things, but perhaps I'm wrong. You might find something useful on CRAWDAD. Most of the datasets are for higher layers, but there appears to be sample data in the RF section. http://crawdad.cs.dartmouth.edu/ Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LTE LTE-Advanced using GNU Radio
On Tue, Aug 2, 2011 at 7:31 PM, Lin HUANG huanglin.b...@gmail.com wrote: This link is for download. https://twiki.eurecom.fr/twiki/bin/view/OpenAirInterface/GetSources But the username seems not usable. You have to contact the server administrator to get an account. I couldn't find any contact information for the administrator or anything on getting access. Do you know where I can find that information? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms
On Wed, Jul 27, 2011 at 1:23 PM, Colby Boyer colby.bo...@gmail.com wrote: Hi all, I'm running a duplex system on the USRP1; using UHD drivers (about 1 month old). For the sample rates, I have 640KHz to the USRP and 1MHz from the USRP. The turn around time for a simple amplitude detected signal is approx 20ms, which is crazy high. Btw, I'm measuring the latency (approx) by observing the nitems_written() method for the block that produces samples for the sync. I'm running UHD and gnuradio with real time threading enabled and giving the gnuradio app a nice of -20. Since this happens before any math occurs, I assume the kernel is lagging on this. Could switching to a modified kernel with realtime improvement patches help? The short answer is that using the RT patch series won't perform any magic and bring across the board reductions in measured latencies. The longer answer is, of course, more complicated. If you want straightforward solutions, try removing other peripherals from the USB bus and disabling all power management (preferably from the kernel). The latter can be particularly sinister when it comes to tracking down latency bugs. Once upon a time, I wrote a kernel module to handle a hard interrupt off of a parallel port and trigger responses from within kernel space (out another pin) and userspace (submitting transfers to libusrp). An external scope was was used for timing measurement. Response times were on average in the single and 10's of microseconds respectively, but differed drastically based on many factors. The main ones were CPU load, power management, and other devices on the USB bus. When it comes to RT patches, you need to consider that the objective is typically containing maximum latencies and not necessarily minimal or average times. In certain cases, average latencies using RT code may be even be higher than the mainline version. When I ran the tests, differences between mainline (somewhere around 2.6.31) and RT series kernels were initially limited, but became apparent when running at near 100% CPU load. In contrived cases, the maximum latency on the normal kernel could increase without bound, which would be more limited on the RT kernel. To sum it up, RT changes to the kernel will have an effect, but it probably won't be immediately obvious. I would start from more obvious areas - for example by seeing what power management is up to. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Performance on ARM Cortex-A8
On Fri, Jul 15, 2011 at 1:47 PM, Marcus D. Leech mle...@ripnet.com wrote: On 07/15/2011 04:42 PM, Philip Balister wrote: From a quick look at Tom's oprofile results, first find out who is calling into libm and see if you can change the block to stopp calling libm. For example, calculate sin/cos via a table approximation (I think GNU Radio already does that). I think libm already does that, too (table-based SIN/COS), not sure. More symbols. http://ttsou.github.com/gnuradio/dab_demod_more_symbols.txt CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples %image namesymbol name 2013 16.0642 no-vmlinux/no-vmlinux 1329 10.6057 libm-2.12.2.so__kernel_cosf 1250 9.9753 libm-2.12.2.so__kernel_sinf 1108 8.8421 libgcc_s.so.1 /lib/libgcc_s.so.1 520 4.1497 libm-2.12.2.so__ieee754_rem_pio2f Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Performance on ARM Cortex-A8
On Wed, Jul 13, 2011 at 1:40 AM, Riadh Elloumi riadh.ello...@parrot.com wrote: Hi all, I complied DAB demodulation for ARM Cortex-A8 (TI OMAP 3). It successfully demodulate DAB+ but spends 13 seconds decoding 1 second of radio baseband (USRP file). I tested the demodulator with similar results. Decoding a file that takes a few seconds on my desktop takes over a minute on the ARM. Why is gnu radio too slow demodulating DAB+? Do you have some figures of CPU consumption on ARM Cortex cores? Is there some optimization I missed for the platform? The performance limitation in this case largely comes from floating point math performance, though that's a vague and not particularly useful conclusion. OProfile report: http://ttsou.github.com/gnuradio/dab_demod_oprof.txt OProfile report with symbols: http://ttsou.github.com/gnuradio/dab_demod_symbols.txt Thomas Profiling through timer interrupt TIMER:0| samples| %| -- 3542 28.4727 libm-2.12.2.so 2976 23.9228 libgnuradio-core-3.4.1git.so.0.0.0 1637 13.1592 no-vmlinux 1151 9.2524 libgcc_s.so.1 1130 9.0836 libgnuradio-dab-3.3.0.so.0.0.0 758 6.0932 libfftw3f.so.3.2.4 549 4.4132 libc-2.12.2.so 407 3.2717 libpthread-2.12.2.so 120 0.9646 libpython2.6.so.1.0 82 0.6592 libboost_thread.so.1.45.0 72 0.5788 python TIMER:0| samples| %| -- 72 100.000 [vectors] (tgid:8032 range:0x-0x1000) 6 0.0482 ld-2.12.2.so 5 0.0402 busybox 3 0.0241 time.so 2 0.0161 oprofiled Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Performance on ARM Cortex-A8
On Fri, Jul 15, 2011 at 1:24 PM, Marcus D. Leech mle...@ripnet.com wrote: On 07/13/2011 04:40 AM, Riadh Elloumi wrote: I used all the optimized code for Cortex-A8 like dotprod_ccf_armv7_a.c. My compilation flags are: -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon -O2. I used fftw-3.2.2. What does -mfloat-abi=softfp do? Does that cause software floating-point to be used? If it does, then your floating-point performance is going to be completely awful. No, it's one way of specifying hardware instructions. http://gcc.gnu.org/onlinedocs/gcc-4.4.6/gcc/ARM-Options.html `softfp' allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions. Use -mfloat-abi=softfp with the appropriate -mfpu option to allow the compiler to generate code that makes use of the hardware floating-point capabilities for these CPUs. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unable to open USRP-E100
On Tue, Jun 28, 2011 at 2:57 PM, Praveen Vikram praveen.bou...@gmail.com wrote: Thanks Josh and Thomas, I followed the current instructions on the wiki and updated the kernel modules (for my current 2.6.35 kernel). Now I'am able to run uhd_usrp_probe with this image http://www.ettus.com/downloads/uhd_images/usrp_e100_fpga5.bin. Thomas, I didn't realise the instructions to update the kernel to 2.6.38 was in the OpenBTS section, thanks for pointing it out. I've been updating the general E100 wiki throughout the day. Pardon me if some links are broken in the meantime. The OpenBTS image instructions were initially written as a special case, but the procedure is general enough to apply to other cases. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Four Oh Four! gnuradio.org again...
On Wed, Jun 22, 2011 at 4:25 AM, Tom Rondeau trondeau1...@gmail.com wrote: Martin, That was odd. When I clicked on your link, it too me to: http://gnuradio.org/redmine/wiki/gnuradio/ That's the old-style Redmine layout. The new one is: http://gnuradio.org/redmine/projects/gnuradio/wiki Which makes more logical sense for one thing. If you go to this link directly, do you have any problems? And yes, I guess it's something to do with caching somewhere. Speaking of caching, search engines don't seem to have picked up on the changes yet. While I'm sure that the updates will eventually propagate, is it possible to add redirects in the meantime? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using fftw for neon with gnuradio
On Wed, Jun 22, 2011 at 2:13 PM, Philip Balister phi...@balister.org wrote: Did you rerun configure adding -fPIC to CFLAGS? I ddi get the library to build as a shared library. That worked for me. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSM not detecting station, USRP1, FA-SY1, WBX, DBS
On Tue, Jun 7, 2011 at 3:28 AM, Paul Lambert the.real.sen...@gmail.com wrote: Hello list, I'm having a lot of trouble here while trying to make openBTS work with my USRP1 to play with GSMs. This question belongs on the OpenBTS list. First of all, a little description of my setup: Software: openbts-2.6.0Mamou gnuradio v3.4.0git-130-g207a2ae7 UHD from git OS: ubuntu 11.04 # sudo lsusrp USRP 0 serial number 4c76a203 RX d'board A: WBX NG RX RX d'board B: DBS Rx TX d'board A: WBX NG TX TX d'board B: none The combination of version 2.6.0-Mamou and WBX isn't supported. Official releases and the mainline tree only support operation with dual RFX900/1800 d'boards. Understandably, this can be easily missed when browsing the wiki page. The FAQ, however, makes this clear and provides a solution for the WBX. http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSFAQ /usr/local/share/gnuradio/examples/usrp/usrp_benchmark_usb.py Max USB/USRP throughput = 32MB/sec I'm using a FA-SY clock to get 52Mhz and I followed the guide in [1] I didn't modify any of the code, since I'm using gnuradio 3.4. (But I adapted my OpenBTS.config) When I start openBTS I get the following output: http://pastebin.com/raw.php?i=nKbG4j3z (I pasted the whole output) These messages are normal. Read the TRX log and you might find a RXTUNE error, which will be the only sign that something is wrong. Here is the openBTS config I use: http://pastebin.com/raw.php?i=aUQfYWGu (This is the last I used, but I tried several other configs) Nothing wrong here. I would be glad if somebody had an idea where I could look next. http://gnuradio.org/redmine/wiki/1/OpenBTSUHD http://lists.sourceforge.net/lists/listinfo/openbts-discuss Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] libusb1 not the solution to USRP crashing
On Sat, May 28, 2011 at 12:11 PM, Brett L. Trotter br...@webtrotter.com wrote: I just discovered the not well published --with-fusb-tech=libusb1 option to configure, hoping to resolve the USRP1 non-uhd crashing issues myself and one other person are seeing when the flowgraphs do a lock or stop. Unfortunately, I still see the same lockup, which rules out any libusb-0.1 possibilities. I removed libusb-devel from my system and recompiled gnuradio with the libusb1 option. You can see libusrp in the ldd here as well. Is there an error code given when this occurs? and when you attempt to restart after it crashes? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
On Mon, May 30, 2011 at 5:20 AM, Johannes Schmitz jsem...@gmx.de wrote: We tried to run the code on Ubuntu 10.04, 10.10 and 11.04. Every time we get the fusb error :( It seems we have to throw away our USRP1's and move to USRP2... I'm not able to reproduce this error with the posted examples. Please try compiling with the --fusb-tech=libusb1 option and post any error output. It may not solve the problem, but debugging with libusb is simpler than debugging through the kernel. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
On Mon, May 30, 2011 at 6:26 PM, Brett L. Trotter br...@webtrotter.com wrote: I've seen the error with both fusb tech libusb1 and 0.1 as well as on various desktops and laptops and operating systems from various vendors. For what its worth, our USRPs are low serial number (no software serial, physical serial around 250). I don't know if that makes a difference. I can see the course of events that are happening, but when something goes wrong, is there an error code or message? Something like, Shut 'er down Clancy, she's pumping mud! The message fusb: (rd status -2) No such file or directory is a gnuradio error message specific to libusb-0.1. I'm curious about errors being generated by libusb-1.0, which would be more helpful for debugging purposes. When you attempt to reestablish a USB connection after a crash, it tells you something no? or does it silently hang? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] libusb-0.1 versus libusb-1.0
On Fri, May 27, 2011 at 1:08 AM, Brett L. Trotter br...@webtrotter.com wrote: So after discovering that while I had libusb-devel-0.1 and libusb1-devel-1.0.3 installed on my RHEL-6 machine here (and ubuntu), gnuradio compiled against 0.1 despite 0.1 being ancient and unsupported. I then removed libusb-devel and gnuradio fails to configure. libusb-1.0 isn't used unless specified. ./configure --with-fusb-tech=libusb1 So just what is the status with libusb. Should it be compiling against libusb-0.1 or should it be compiling against libusb-1.0 and if so, why isn't configure finding libusb-1.0 on Ubuntu or RHEL-6? Either (if not UHD). The differences are minor, though the reasons are more subtle. A quick search may reveal that libusb-1.0 supports asynchronous I/O which is substantially faster than its predecessor, but this is deceiving with regards to gnuradio. The libusrp driver worked around limitations of libusb-0.1 through a hybrid case of using underlying - platform specific - calls (usbfs in the case of Linux) where high throughput was needed. libusb-1.0 adds a layer on top of the kernel interfaces and the platform specific calls are removed. Since the libusb-1.0 asynchronous interface is largely modelled after the Linux kernel interface, this layer is thin and the differences are negligible in the most cases. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
On Fri, May 27, 2011 at 7:28 AM, Johannes Schmitz jsem...@gmx.de wrote: I am getting this error: fusb: (rd status -2) No such file or directory What does it mean and what can I do to solve this. Crazy thing is it doesn't happen every time I call my rx script. I tried to pull usrp power plug and usb plug but it did not help. The error is coming from the kernel. Can you describe your system setup? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OpenBTS on USRP E100
On Tue, Apr 5, 2011 at 12:55 PM, Khalid Jamil khalid.ja...@gmail.com wrote: Hello, Does anyone know if openBTS can be run on E100 standalone? The current OpenBTS-UHD code will compile and run on the E100, but is limited by the default 64 MHz clock configuration and required sample rate conversion. I will be pushing development code to work with the 52 MHz transceiver shortly within the coming weeks. The primary source for public OpenBTS information is the wiki, which I will update when I get to an appropriate machine late this evening. http://www.gnuradio.org/redmine/wiki/1/OpenBTS Also, please address OpenBTS questions to the openbts-discuss mailing list. http://sourceforge.net/mail/?group_id=230904 Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] openbts and local gnuradio
On Tue, Mar 22, 2011 at 8:47 PM, sur...@stud.ntnu.no wrote: Hello. Pardon if it was discussed before - quick googling failed me. How do I specify local installation of gnuradio instead of system-wide for openbts build - something like: ./configure --gnuradio-prefix=/home/user/gnuradio ? pkg-config will take care of this for you. Set the PKG_CONFIG_PATH environment variable to point to the directory of the installed usrp.pc file. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard
On Wed, Feb 23, 2011 at 11:25 PM, Almohanad Fayez alfa...@aol.com wrote: I was wondering about people's experience with the UHD driver on the E100 or the Beagleboard. I am able to use it to receive IQ data from the USRP but I can't seem to transmit anything from it ... if I take the same flowgraph to a laptop I'm able to transmit IQ using the same USRP/daughterboard and the UHD driver however when I try to run the same transmitter on the Beagleboard and I check my spectrum analyzer I don't see anything After some bad judgement on my part, my E100 is back up and running. Now with the USRP1 attached, I can transmit up to 4 Msps before I get underruns using tx_timed_samples. The scope output checks out as well. With gnuradio, however, I get underruns rather severely at any sample rate; I didn't do any digging to find out why. I already did a signal capture before sending to the USRP and made sure that there is data getting pushed through ... is there a problem with UHD/USRP sinking on the E100 and the Beagleboard ??? I also made sure that I'm using the latest UHD firmware on the beagleboard. Can you run some of the UHD examples without gnuradio? The following is the version info printed when I run the flowgraph: linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500; UHD_0001.20110224034946. On the E100: linux; GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100; UHD_003.20110226000831.77641c6 Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [USRP-users] UHD Announcement - February 25rd 2011
On Fri, Feb 25, 2011 at 8:32 PM, Josh Blum j...@ettus.com wrote:
Hello list,
In preparation for the coming gnuradio release, and the cut-over from
next to master, changes have been pushed to both the uhd.git master
branch and the gnuradio.git next branch.
I'm getting the following timeouts after the update. I presume this has
something to do with buffering since it always occurs at the same packet
number - code change at end. Same result on e100 and rlt NIC's.
[ttsou@fischer examples]$ ./tx_timed_samples --secs 4 --nsamps 40 --rate
400e3 --dilv --spp 864
linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
UHD_003.20110226000831.77641c6
Creating the usrp device with: ...
Current recv sock buff size: 5000 bytes
mboard0 MIMO master
Using Device: Single USRP:
Device: USRP2/N Series device
Mboard 0: USRP-N210 mboard
RX DSP 0: USRP-N210 ddc0
RX Channel: 0
RX Dboard: USRP-N210 dboard (rx unit)
RX Subdev: Unknown - Unknown (0x)
TX DSP 0: USRP-N210 duc0
TX Channel: 0
TX Dboard: USRP-N210 dboard (tx unit)
TX Subdev: Basic TX (0x) - AB
Setting TX Rate: 0.40 Msps...
Actual TX Rate: 0.40 Msps...
Setting TX Freq: 0.00 Mhz...
Actual TX Freq: 0.00 Mhz...
Setting device timestamp to 0...
Send timeout... Sent 362 samples of packet 237
Send timeout... Sent 0 samples of packet 238
Send timeout... Sent 0 samples of packet 239
Send timeout... Sent 0 samples of packet 240
Send timeout... Sent 0 samples of packet 241
...
Thomas
---
host/examples/tx_timed_samples.cpp |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/host/examples/tx_timed_samples.cpp
b/host/examples/tx_timed_samples.cpp
index f10d7e4..1f87ae3 100644
--- a/host/examples/tx_timed_samples.cpp
+++ b/host/examples/tx_timed_samples.cpp
@@ -106,7 +106,8 @@ int UHD_SAFE_MAIN(int argc, char *argv[]){
//send will backup into the host this many seconds before sending:
seconds_in_future + 0.1 //timeout (delay before transmit + padding)
);
-if (num_tx_samps samps_to_send) std::cout Send timeout...
std::endl;
+if (num_tx_samps samps_to_send)
+std::cout Send timeout... Sent num_tx_samps samples
of packet i std::endl;
if(verbose) std::cout std::endl boost::format(Sent %d samples)
% num_tx_samps std::endl;
}
--
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [USRP-users] UHD Announcement - February 25rd 2011
On Fri, Feb 25, 2011 at 8:32 PM, Josh Blum j...@ettus.com wrote: --- -- re-clocking support --- Re-clocking support has been added to the API: http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a99254abfa5259b70a020e667eee619b9 On a USRP1 board, you can specify usrp-set_master_clock_rate(52e6) so that the driver knows to use 52MHz in its calculations. Note that this does not really modify the clock rate, it just informs the driver of the hardware changes. In contrast, when setting the clock rate on the usrp-e100, the driver will dynamically reprogram the registers on the clock generator to obtain the desired rate. See application notes: http://www.ettus.com/uhd_docs/manual/html/usrp_e1xx.html#changing-the-master-clock-rate I've been getting the following error during make since I changed the clock rate. Did I brick the FPGA? I can't seem to find the special pass-through image anywhere. USRP-E100 clock control: VCO calibration timeout Vitals: GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100; UHD_003.20110226000831.77641c6 Linux version 2.6.35 (balister@astro) (gcc version 4.5.2 20101026 (prerelease) (GCC) ) #1 PREEMPT Fri Nov 5 08:56:09 PDT 2010 usrp_e100_fpga_compat3_feb_25.bin Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usb errors while stopping flowgraph
On Sat, Feb 26, 2011 at 12:34 AM, Brett L. Trotter br...@webtrotter.com wrote: I've got several different flowgraphs here that upon shutting down some portion of the time, they emit a series of errors and then totally tank my USB controller on a number of test systems, requiring a full system reboot to reset the USB (the RHEL6 box I'm using has USB modules compiled into the kernel, so rmmod isn't an option). The flowgraphs stop normally about 3/4 times. It seems to be chance when its in some odd state that it won't shutdown right. Errors emitted: usb_control_msg failed: error sending control message: Connection timed out write_cmd failed You should consider switching over to the new UHD blocks as the old driver is no longer in active development. You can try building with the libusb-1.0 backend (--with-fusb-tech=libusb1) to see if the problem goes away, but UHD is the long term solution. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard
On Sun, Feb 27, 2011 at 11:39 PM, Almohanad Fayez alfa...@aol.com wrote: I think I made some progress in diagnosing the UHD/Beagleboard USRP1 issue. I've tried bitbaking Philip's GNU Radio 3.2.1 recipe and the compilation fails because of the libusb-0.1.12 link, more specifically the libusb-gnur.a library. For some reason GCC is expecting the library to have the -fPIC flag passed when building the library which doesn't make sense since it's trying to link against a static library and not a shared librar ... it was complaining about an ARM_MOV or something like that assembly command. To my understanding the libtool included in the libusb should make sure that such confusion doesn't happen which in using GCC 4.3 was not an issue but with the GCC 4.5 included in the new tree is an issue. UHD uses libusb-1.0 and does not support libusb-0.1. Despite some similarities in the API, version 1.0 is a complete rewrite there is no compatibility or relation between versions. In that sense, the gnuradio 3.2 recipe is completely unrelated to UHD. I also tried incorporating the libusb fix against the GNU Radio GIT recipe but the configure stage fails because gnuradio can't find the USB_BULK_WRITE function in the libusb library from libusb-0.1.12 which when I looked is actually there. When I bypass the configure check for USB_BULK_WRITE the gnuradio compilation fails at the same stage as gnuradio 3.2.1. I feel like the libusb-0.1.12 static library is corrupt for some reason more specifically I think libtool might be the culprit. If you are using libusb-0.1 and the gnuradio driver, you generally _don't_ want to be using the mentioned libusb calls, which are synchronous (slow). Normally, with libusb-0.1, the control and setup functions go through libusb, while data flows through a separate OS specific implementation - usbdevfs in the case of Linux. The only time you should be seeing usb_bulk_write is when configure falls back to the synchronous calls in the absence of any fast version. Now the Linux implementation does have some evil bits, so perhaps this isn't surprising. I assume that USB_BULK_WRITE is used in the USRP sink UHD block which might explain why I can receive but I can't write using the UHD driver. The libusb-0.1.12 fix included in the UHD driver, did it use GCC 4.5? did it use libusb-0.1.12? an older or newer version maybe? did it use a different libtool? Again, usb_bulk_write and libusb-0.1.12 have no relation to UHD. I need to find a way to pass the -fPIC flag to the configure stage of libusb-0.1.12 unfortunately I can't seem to find an easy way to do it and I'm about to head out of town for a few days. Other than that doese anyone have any suggestion? In UHD with libusb-1.0, sends and receives are treated similarly (USB is host driven) where pre-allocated buffers are submitted and retrieved from the device. The difference is mainly in flags and endpoint settings; the problem, IMO, is unlikely to be build related. Of course, that doesn't provide any insight into why this is only coming up on the Beagle. I'd like to recreate this issue on my newly setup E100, but, at the moment, I'm not seeing any USB devices, and I think I just bricked my FPGA. So I need to get a little bit more settled until I can try out additional things. Perhaps later this week... Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FX2 Controller/ GPIF questions
On Wed, Feb 16, 2011 at 3:54 AM, Arya Santini arya.santi...@gmail.com wrote: Hi All, Can anyone shed some light on how the FX2 firmware / GPIF handles simultaneous reads and writes? I mean if I set up my USRP1 to receive and transmit simultaneously, what is happening exactly down there at the GPIF level? Given that there are two GPIF waveform configurations one each for Read and Write, are there two concurrent instantiations of the FIFO state machine during simultaneous read/ writes for full duplex operation , or in other words are there separate FIFO state machines operating in two configurations at the same time? If the GPIF state machine is in only one configuration (FIFOWr or FIFORd) at one time, how is true full duplex communication possible? There are separate GPIF waveforms for reads and writes, which occur as 512 byte bursts when data and buffer space are available. FIFO buffers in both directions allow for full duplex operation. There's a good summary of the main run loop on the wiki page. http://gnuradio.org/redmine/wiki/1/UsrpFAQFX2 Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Timestamp Error on Receive
I'm getting unexplained behavior receiving timed samples in continuous
mode with yesterday's merge. First run after boot is fine, but I get
overruns and a bizarre timestamp on subsequent runs. This occurs with the
USRP2 and N210. Running rx_timed_samples with the following diff
reproduces the issue. Thoughts? Thanks.
Thomas
--Cold start
Begin streaming 1000 samples, 3.00 seconds in the future...
Got packet: 362 samples, 3 full secs, 0.00 frac secs
Got packet: 362 samples, 3 full secs, 0.58 frac secs
Got packet: 362 samples, 3 full secs, 0.000116 frac secs
--Subsequent runs
Begin streaming 1000 samples, 3.00 seconds in the future...
OGot packet: 362 samples, 3 full secs, 0.129991 frac secs
OGot packet: 362 samples, 3 full secs, 0.58 frac secs
Got packet: 362 samples, 3 full secs, 0.000116 frac secs
diff --git a/host/examples/rx_timed_samples.cpp
b/host/examples/rx_timed_samples.cpp
index a19532f..e3f60ee 100644
--- a/host/examples/rx_timed_samples.cpp
+++ b/host/examples/rx_timed_samples.cpp
@@ -82,8 +82,7 @@ int UHD_SAFE_MAIN(int argc, char *argv[]){
std::cout boost::format(
Begin streaming %u samples, %f seconds in the future...
) % total_num_samps % seconds_in_future std::endl;
-uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
-stream_cmd.num_samps = total_num_samps;
+uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
stream_cmd.stream_now = false;
stream_cmd.time_spec = uhd::time_spec_t(seconds_in_future);
sdev-issue_stream_cmd(stream_cmd);
--
1.7.3.4
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Expected behavior during underruns
On Tue, Dec 14, 2010 at 6:34 PM, Josh Blum j...@joshknows.com wrote: Our observations shows also that the usrp2 doesn't drop any samples when an underrun occur. If we drop samples at the host, can we get a continous stream of sample at 25Msamp/s that is synchronous? What is your maximum continous bandwidth? Underflows occur on transmit, nothing can drop because this is a lack of samples. If I understand correctly, the transmit situation that Patrik describes is behaviour _after_ the underflow. For a continuous stream, the effect to subsequent samples is an added time offset - equal to the duration of the underflow - relative to the original start of the stream. For certain real-time applications, paired spectrum TDMA for example, this makes underruns devastating. In these cases, samples that were supposed to be transmitted when the underrun occurred, but didn't for whatever reason, are irrelevant and need to be dropped rather than transmitted best effort. AFAIK, the only way to currently handle this is to catch the underrun at the host and drop a handful of packets so that the next start-of-burst reaches the USRP2 ahead of the deadline. I've been looking in the source code and tried to find out where to implement the sample dropping. My thoughts so far is that it should be somewhere in vrt_packet_handler.hpp and/or io_impl.cpp in the send functions and get_send_buffs function. Is there something that you think the streaming API is missing please let me know. I think you can accomplish what you need with the API without modifying the underlying implementation. I agree. Poking around the guts is a bad place to start and unnecessary. The OpenBTS USRP2 implementation uses get_time_now() to resync the host when an underrun occurs. Obviously, you shouldn't bother sending a packet if the difference between usrp time and the transmit timestamp is negative or near zero. http://github.com/ttsou/openbts-uhd/blob/master/public-trunk/Transceiver/UHDDevice.cpp Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build broken today
On Tue, Nov 16, 2010 at 4:38 PM, Marcus D. Leech mle...@ripnet.com wrote: I did a git pull for both UHD (master) and gnuradio (next) today, and a make clean; make in both places. The build is currently broken: ... /usr/local/include/uhd/types/ranges.hpp:59: Error: Syntax error in input(3). make[5]: *** [.deps/uhd_swig-generate-stamp] Error 1 make[5]: Leaving directory `/home/mleech/gnuradio/gr-uhd/swig' Different but possibly related breakage in my applications after today's pull. Looks like the API may have changed a bit. UHDDevice.cpp:260: error: ‘struct uhd::gain_range_t’ has no member named ‘max’ UHDDevice.cpp:260: error: ‘struct uhd::gain_range_t’ has no member named ‘min’ Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] external ref
On Wed, Nov 10, 2010 at 12:44 AM, Brett L. Trotter br...@webtrotter.com wrote: Does any alteration to code or firmware need to be made in order to get a USRP2 to lock to an external 10MHz reference? No firmware changes with UHD. Code looks something like this. uhd::clock_config_t clock_config; clock_config.ref_source = uhd::clock_config_t::REF_SMA; clock_config.pps_source = uhd::clock_config_t::PPS_SMA; clock_config.pps_polarity = uhd::clock_config_t::PPS_NEG; dev = uhd::usrp::single_usrp::make(dev_addr); dev-set_clock_config(clock_config); Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cant open usrp
On Mon, Oct 25, 2010 at 11:15 AM, zhdiamond zhaojinh...@hotmail.com wrote: My USRP has something wrong when started. when i want to open USRP, I input the command: usrp_fft.py -R B. but the system mentioned that: RuntimeError: cant open usrp, failed to load fpga bitstream /usr/share/usrp/rev4/std_2rxhb_2tx.rbf. what 's wrong with my USRP? how can I fixed it? During the fpga load, one of the LEDs will turn on and stay on for the duration the loading process, which is about one second. If the LED never turns on, there is a problem occurring prior to the loading of the fpga. Otherwise, it is likely that the fpga load itself is failing. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio and usrp_standard.h: No such file or directory
On Tue, Sep 21, 2010 at 10:20 AM, Fabrizio Tappero fabrizio.tapp...@gmail.com wrote: Dear All, I'd like to add a little piece of information about this problem. if I try to compile the previously mentioned code with: g++ usrp_test_c++.cpp -o testusrp `pkg-config --cflags usrp` `pkg-config --libs usrp` and I change: #include usrp_standard.h in: #include usrp/usrp_standard.h #include stdio.h the code from here: http://gnuradio.org/redmine/wiki/1/UsrpFAQCppInterface almost compile... As you discovered, there are a number of problems with the example code. I made some quick changes to the wiki page, which was quite dated. It should now compile with gnuradio 3.3 and recent Linux distributions. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1, GNU Radio, UHD???
On Mon, Sep 13, 2010 at 5:20 PM, Mason Scott mason.scott1...@yahoo.com wrote: I have to do my diploma work and I have to us an USRP to make an application, to be able to read some data from a hardware, to show how it can be integrated in a system, I'not giving any more details because it's not important. My whole project will be written in VisualStudio this is why I want to use the Windows environment. USRP1 support in UHD depends on libusb-1.0, which currently only has windows support in beta form. Therefore, I would only recommend using USRP1 with UHD in windows if you're willing to deal with experimental dependencies. Until the windows backend in libusb becomes stable (hopefully in the next few months), most USRP1 windows users will be better served by the gnuradio driver, which uses libusb-win32. My USRP1 is running, powered, but what's next? I tried to install GNU Radio with CygWin and MinGW but no success, then I read something related to UHD, but it's not clear, how much support it brings for USRP1, and what I will be able to do, or how to use it. Hopefully, in time, timestamped sample support for the USRP1 will be added to UHD. In the meantime, USRP1 features in UHD and GNU Radio are identical, though with different host side implementations. Could anyone (those who have installed successfully GNU Radio or used UHD) to explain in some big (or detaild) steps what they have done. Perhaps you could mention what specific problems you ran into while installing GNU Radio? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: libusb error on Mac OS X when building uhd driver
On Sun, Sep 5, 2010 at 1:24 PM, Josh Blum j...@joshknows.com wrote:
On 09/05/2010 04:11 AM, Elvis Dowson wrote:
Hi,
More specifically, there is a problem with calls to
libusb_cpu_to_le16(x) in libusb.h
/** \def libusb_cpu_to_le16
* \ingroup misc
* Convert a 16-bit value from host-endian to little-endian format. On
* little endian systems, this function does nothing. On big endian
systems,
* the bytes are swapped.
* \param x the host-endian value to convert
* \returns the value in little-endian byte order
*/
#define libusb_cpu_to_le16(x) ({ \
union { \
uint8_t b8[2]; \
uint16_t b16; \
} _tmp; \
uint16_t _tmp2 = (uint16_t)(x); \
_tmp.b8[1] = _tmp2 8; \
_tmp.b8[0] = _tmp2 0xff; \
_tmp.b16; \
})
That seems horrendous, is that even valid c code? Its better defined as a
function, or maybe a preprocessor conditional byteswap... Is it fixed in the
libusb10 repo at least?
In libusb, the macro was converted with commit
7ba92cff94bbba19284749c614c26141d3023f37
libusb_cpu_to_le16: macro-static inline function
The error has been reported with Windows and gcc-4.4, which led to the
patch. I'm not sure exactly what caused it to surface in this case.
Oddly enough, the purpose of that macro to begin with was for OSX
support in making endianness macros endian-independent. Apparently,
cross-compiling issues prevent a preprocessor conditional
implementation.
Elvis, you can either rebuild libusb from git or wait for the v1.0.9
libusb release.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the USRP1 for GOES LRIT reception...
On Sun, Sep 5, 2010 at 1:03 PM, Michael Kimzey mckim...@hotmail.com wrote: Hello all. I'm a bit of a noobie and getting my feet wet here. I hope to use my recently received USRP1 to receive the GOES weather satellite LRIT data using software from their site. (here: http://www.goes-r.gov/hrit_emwin/index.html ) First, I was wondering if there was anyone else out there interested in/doing the same. Second, I loaded up the software and followed the included directions (setting environment variables, etc) but it seems that the firmware wouldn't load up. (the USRP1 is installed and recognized by windows, though) Here is the output: --C:\Program Files\HRIT Radioemwinr == Tracking LIVE SATELLITE Using ETTUS BOX === The current date is 09/05/10 The current time is 12:14:00 Clock.Frequency: 64.0 MHz == ACQ-Engine ENABLED == Can't find firmware: std_Aerospace.ihx PATH= C:\Program Files\HRIT Radio This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. C:\Program Files\HRIT Radio ---As an FYI, the required firmware (std_Aerospace.ihx) is in this directory and has the exact same spelling. So, if anyone can offer some insight that would be cool. I'll also be asking the developers and update this list if I hear anything. I took a peek at the receiver code. Since it reuses the USRP code from GNURadio the following should apply. Assuming that you have the USRP_PATH environment variable set, the firmware file should be in USRP_PATH\rev4\ and not in the base directory specified by the variable. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 10 bit samples
On Wed, Aug 25, 2010 at 9:58 AM, Vincenzo Pellegrini wwvi...@gmail.com wrote: Hi everybody, Just a very simple question: Is it possible to obtain 10 bit samples out of USRP (either 1 or 2) by using suitable libusrp primitives / parameters? No. But you can produce 8-bit samples on the USRP1 by appropriately setting the FR_RX_FORMAT register. You can set it through the standard interface. This option is not available on the USRP2. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
On Tue, Aug 24, 2010 at 4:18 PM, Mark J. Blair n...@nf6x.net wrote: Now usrper appears to be happy: ~/gnuradio% usrper -v load_standard_bits usrper: found unconfigured usrp; needs firmware. ~/gnuradio% usrper -v get_hash0 hash: ???7???g8!?_Md ~/gnuradio% usrper -v set_hash0 deadbeef ~/gnuradio% usrper -v get_hash0 hash: deadbeef ~/gnuradio% While I don't know what any of those usrper commands are actually doing, at least they seem to be not-crashing! Good to hear that it's all working. Unless you're writing your own firmware, usrper is usually limited in terms usefulness. If you're wondering, the hash commands are used for conditional loading of the fpga or USB controller. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp1 suddenly stops communicating
On Wed, Aug 4, 2010 at 3:30 PM, Patrik Tast pat...@poes-weather.com wrote: Hi All, The free USRP1 has suddenly decided to stop communicating. We suspect (from the output) that it might be an USB problem? Very likely. It runs for about 30 - 60 secs and then freezes. The led on the motherboard is still blinking though. We've tried to plug into other USB ports and using different cables but the result is always the same. Is the led blinking slow - signifying loaded firmware - or fast like at power up? Do any notable USB messages show up in the dmesg output? Have you tried the usrp on another machine? F12 is used with all the latest updates. Screenshots when it halts @ http://www.poes-weather.com/~patrik/usrp/usb-fail/ Notice the serialnumber is all zeros, perhaps cos it is a preversion? What is the actual serial number marked on the board? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] set_auto_tr() and set_enable()
2010/8/2 shanki shanki...@163.com: thanks Thomas, in order to test these two calls, i write some test codes: i put a rxpath and a txpath in one topblock, my daughterboard is RFX2400, and i want to perform receiving while transmiting. Firstly, i used set_auto_tr(True), but i did't receive anything. Secondly, i used set_auto_tr(False), and set_enable(True), then i could receive one packet after every transmitted packet. does that make any sense? in my opinion, the results should be on the contrary, but .. could you give me some explanations? thanks, How are your antennas setup and how are you calling set_auto_tr() and set_enable()? Note that tx and rx paths each have their own set of ATR registers that can be configured independently. For the first case, assuming that both ATR masks are enabled for the RFX, the receive mixer will be disabled while transmitting. For the second case, both paths are enabled, which should explain the observed behaviour. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] set_auto_tr() and set_enable()
2010/7/30 蒲盟 shanki...@163.com: Hi , I am confued by set_auto_tr() and set_enable(). In my opinion set_auto_tr(True) means that if there is something to transmit( something sent to the FPGA), the Rx path will be disabled, but if there is nothing sent to the FPGA, then the Rx path will be always enabled. On the other hand, if set_enable(True) is set, no matter whether there is something or not sent to FPGA, the TX path will always be enabled, and Rx path will always be disabled. But could set_auto_tr() and set_enable() be both set to True? if the answer is YES, what will happen? If you look at the daughterboard code, you'll find similarities between the set_auto_tr() and set_enable() calls. Regarding pin output, the difference is the use of ATR registers versus the normal IO register; for ATR masked pins, the ATR registers have precedence. In other words, if set_auto_tr() is set to true, then set_enable() will have no effect. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't find firmware: std.ihx
On Tue, Jul 27, 2010 at 1:25 AM, Craig Tong tngcra...@rrsg.ee.uct.ac.za wrote: Ok. Didn't think it would be in there. Ran the script and it seems to be working correctly now. The bcdDevice is now 1.04 though. I assume this is correct. Looks like it only takes the 4 from the value. Right. It changes to 1.04 after the firmware loads. Thomas Thanks so much for the help guys. Regards Craig Tong Radar Remote Sensing Group University of Cape Town On 27/07/2010 02:36, Thomas Tsou wrote: On Mon, Jul 26, 2010 at 1:39 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi bcdDevice is 0.00 for the verbose lsusb output. Also there doesn't seem to a be a burn-usrp4-eeprom anymore but there is a burn-db-eeprom, unless I'm missing something. The script you need to run can be found in the built source. usrp/firmware/src/usrp2/burn-usrp4-eeprom Disregard the directory naming. Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 23/07/2010 19:49, Thomas Tsou wrote: On Fri, Jul 23, 2010 at 1:51 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: This USRP has been here since before my time but the other guys in the lab seem to think that it was bought directly from Ettus. It has the Ettus Research LLC sticker on it with the Ser number and test date. As for the lsusb. It reports: Bus 001 Device 007: ID fffe:0002 similar to lsusb for the working USRP. That means the EEPROM is being read correctly. Try running lsusb -v and look for the line bcdDevice under the fffe:0002 section. You should be seeing 0.04, which means unconfigured (high byte) and rev4 (low byte). Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 22/07/2010 20:15, Thomas Tsou wrote: On Thu, Jul 22, 2010 at 4:35 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, Thanks for the help, I tracked through the functions that are used to load up the firmware and it turns out that this USRP is reporting its revision number as 0. As such the path to the firmware is always invalid. I managed to get my hands on another USRP just now and it returns revision 4 so my code seems to work correctly. Is this likely to be an EPROM corruption ? That is likely. At usrp power-up, the USB controller reads the eeprom data, which is reported to the host as various identifiers. Either the data is somehow corrupt or not being read. What appears when you run lsusb on the command line? Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 21/07/2010 19:15, Thomas Tsou wrote: On Wed, Jul 21, 2010 at 1:36 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, I'm having some trouble getting my USRP board running with just about any software. It always seems to die with Can't find firmware: std.ihx. I've tried a whole array of applications including usrp_fft.py and similar, usrp_probe and then also the C++ progs (test_usrp_standard_rx and the like). It dies with the same complaint when running the C++ software that we're busy writing. It fails on the line usrp_standard_rx::make( ... ) where the firmware file is specified. It is currently blank (i.e. default) but even if the file is specified explicitly, it still claims that it cannot be found. From what I understand from what is going on in usrp_prims_common.cc if the user specifies a path it should override the default one. Exactly how it formats this path I can't really keep track of and I think something is going wrong there. Under typical installations the path is constructed with /usr/local/share/usrp appended with rev2 or rev4 and the filename. If environment variable USRP_PATH is set, then the revision and filename are appended to that path instead. Read permissions are also checked before the path is returned. As you already suspect, the problem is most likely something minor. Try printing out the path in the find_file() call to see what you're searching for. Thomas I had it working on Ubuntu 9.04 x86 but it stopped working when I updated to 10.04. I tried reinstalling gnuradio 3.2 several times. And also tried the versions from synaptic but always came down with the same error. I've since wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 version of gnuradio but the problem continues. I do have usr/local/share/usrp/rev4/std.ihx and all that goes with it. I can also load the firmware with usrper and then put LED1 on and off so the USRP seems to be working correctly. I do get the feeling I'm missing something very obvious here because it seems the last instances of this sort of problem date back to 2007. Still I just can't put my finger on whats wrong. Any advice would be greatly appreciated. regards Craig ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http
Re: [Discuss-gnuradio] Can't find firmware: std.ihx
On Mon, Jul 26, 2010 at 1:39 AM, Craig Tong tngcra...@rrsg.ee.uct.ac.za wrote: Hi bcdDevice is 0.00 for the verbose lsusb output. Also there doesn't seem to a be a burn-usrp4-eeprom anymore but there is a burn-db-eeprom, unless I'm missing something. The script you need to run can be found in the built source. usrp/firmware/src/usrp2/burn-usrp4-eeprom Disregard the directory naming. Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 23/07/2010 19:49, Thomas Tsou wrote: On Fri, Jul 23, 2010 at 1:51 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: This USRP has been here since before my time but the other guys in the lab seem to think that it was bought directly from Ettus. It has the Ettus Research LLC sticker on it with the Ser number and test date. As for the lsusb. It reports: Bus 001 Device 007: ID fffe:0002 similar to lsusb for the working USRP. That means the EEPROM is being read correctly. Try running lsusb -v and look for the line bcdDevice under the fffe:0002 section. You should be seeing 0.04, which means unconfigured (high byte) and rev4 (low byte). Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 22/07/2010 20:15, Thomas Tsou wrote: On Thu, Jul 22, 2010 at 4:35 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, Thanks for the help, I tracked through the functions that are used to load up the firmware and it turns out that this USRP is reporting its revision number as 0. As such the path to the firmware is always invalid. I managed to get my hands on another USRP just now and it returns revision 4 so my code seems to work correctly. Is this likely to be an EPROM corruption ? That is likely. At usrp power-up, the USB controller reads the eeprom data, which is reported to the host as various identifiers. Either the data is somehow corrupt or not being read. What appears when you run lsusb on the command line? Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 21/07/2010 19:15, Thomas Tsou wrote: On Wed, Jul 21, 2010 at 1:36 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, I'm having some trouble getting my USRP board running with just about any software. It always seems to die with Can't find firmware: std.ihx. I've tried a whole array of applications including usrp_fft.py and similar, usrp_probe and then also the C++ progs (test_usrp_standard_rx and the like). It dies with the same complaint when running the C++ software that we're busy writing. It fails on the line usrp_standard_rx::make( ... ) where the firmware file is specified. It is currently blank (i.e. default) but even if the file is specified explicitly, it still claims that it cannot be found. From what I understand from what is going on in usrp_prims_common.cc if the user specifies a path it should override the default one. Exactly how it formats this path I can't really keep track of and I think something is going wrong there. Under typical installations the path is constructed with /usr/local/share/usrp appended with rev2 or rev4 and the filename. If environment variable USRP_PATH is set, then the revision and filename are appended to that path instead. Read permissions are also checked before the path is returned. As you already suspect, the problem is most likely something minor. Try printing out the path in the find_file() call to see what you're searching for. Thomas I had it working on Ubuntu 9.04 x86 but it stopped working when I updated to 10.04. I tried reinstalling gnuradio 3.2 several times. And also tried the versions from synaptic but always came down with the same error. I've since wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 version of gnuradio but the problem continues. I do have usr/local/share/usrp/rev4/std.ihx and all that goes with it. I can also load the firmware with usrper and then put LED1 on and off so the USRP seems to be working correctly. I do get the feeling I'm missing something very obvious here because it seems the last instances of this sort of problem date back to 2007. Still I just can't put my finger on whats wrong. Any advice would be greatly appreciated. regards Craig ___ 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 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] Standard firmware for 1 rx and 1 tx
On Sun, Jul 25, 2010 at 12:45 AM, Bishal Thapa bdarealt...@gmail.com wrote: Hi GNURadioers, I have a quick question. I am trying to use USRP running gnuradio-3.3.0 with two daughterboards... RFX2400. I am going to use one daughterboard to receive and another to transmit. Do I use the standard firmware that is loaded by default, std_2rxhb_2tx.rbf or is there a std_1rx_1tx.rbf somwhere. My question is, would the performance be better if I were to find and use std_1rx_1tx.rbf. My decimation rate will be 32 and interpolation rate will be 64. I would just use the default fpga file. Your use case is not atypical; performance will depend on the host code rather than what happens on the usrp. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't find firmware: std.ihx
On Fri, Jul 23, 2010 at 1:51 AM, Craig Tong tngcra...@rrsg.ee.uct.ac.za wrote: This USRP has been here since before my time but the other guys in the lab seem to think that it was bought directly from Ettus. It has the Ettus Research LLC sticker on it with the Ser number and test date. As for the lsusb. It reports: Bus 001 Device 007: ID fffe:0002 similar to lsusb for the working USRP. That means the EEPROM is being read correctly. Try running lsusb -v and look for the line bcdDevice under the fffe:0002 section. You should be seeing 0.04, which means unconfigured (high byte) and rev4 (low byte). Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 22/07/2010 20:15, Thomas Tsou wrote: On Thu, Jul 22, 2010 at 4:35 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, Thanks for the help, I tracked through the functions that are used to load up the firmware and it turns out that this USRP is reporting its revision number as 0. As such the path to the firmware is always invalid. I managed to get my hands on another USRP just now and it returns revision 4 so my code seems to work correctly. Is this likely to be an EPROM corruption ? That is likely. At usrp power-up, the USB controller reads the eeprom data, which is reported to the host as various identifiers. Either the data is somehow corrupt or not being read. What appears when you run lsusb on the command line? Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 21/07/2010 19:15, Thomas Tsou wrote: On Wed, Jul 21, 2010 at 1:36 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, I'm having some trouble getting my USRP board running with just about any software. It always seems to die with Can't find firmware: std.ihx. I've tried a whole array of applications including usrp_fft.py and similar, usrp_probe and then also the C++ progs (test_usrp_standard_rx and the like). It dies with the same complaint when running the C++ software that we're busy writing. It fails on the line usrp_standard_rx::make( ... ) where the firmware file is specified. It is currently blank (i.e. default) but even if the file is specified explicitly, it still claims that it cannot be found. From what I understand from what is going on in usrp_prims_common.cc if the user specifies a path it should override the default one. Exactly how it formats this path I can't really keep track of and I think something is going wrong there. Under typical installations the path is constructed with /usr/local/share/usrp appended with rev2 or rev4 and the filename. If environment variable USRP_PATH is set, then the revision and filename are appended to that path instead. Read permissions are also checked before the path is returned. As you already suspect, the problem is most likely something minor. Try printing out the path in the find_file() call to see what you're searching for. Thomas I had it working on Ubuntu 9.04 x86 but it stopped working when I updated to 10.04. I tried reinstalling gnuradio 3.2 several times. And also tried the versions from synaptic but always came down with the same error. I've since wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 version of gnuradio but the problem continues. I do have usr/local/share/usrp/rev4/std.ihx and all that goes with it. I can also load the firmware with usrper and then put LED1 on and off so the USRP seems to be working correctly. I do get the feeling I'm missing something very obvious here because it seems the last instances of this sort of problem date back to 2007. Still I just can't put my finger on whats wrong. Any advice would be greatly appreciated. regards Craig ___ 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't find firmware: std.ihx
On Thu, Jul 22, 2010 at 4:35 AM, Craig Tong tngcra...@rrsg.ee.uct.ac.za wrote: Hi, Thanks for the help, I tracked through the functions that are used to load up the firmware and it turns out that this USRP is reporting its revision number as 0. As such the path to the firmware is always invalid. I managed to get my hands on another USRP just now and it returns revision 4 so my code seems to work correctly. Is this likely to be an EPROM corruption ? That is likely. At usrp power-up, the USB controller reads the eeprom data, which is reported to the host as various identifiers. Either the data is somehow corrupt or not being read. What appears when you run lsusb on the command line? Thomas Craig Tong Radar Remote Sensing Group University of Cape Town On 21/07/2010 19:15, Thomas Tsou wrote: On Wed, Jul 21, 2010 at 1:36 AM, Craig Tongtngcra...@rrsg.ee.uct.ac.za wrote: Hi, I'm having some trouble getting my USRP board running with just about any software. It always seems to die with Can't find firmware: std.ihx. I've tried a whole array of applications including usrp_fft.py and similar, usrp_probe and then also the C++ progs (test_usrp_standard_rx and the like). It dies with the same complaint when running the C++ software that we're busy writing. It fails on the line usrp_standard_rx::make( ... ) where the firmware file is specified. It is currently blank (i.e. default) but even if the file is specified explicitly, it still claims that it cannot be found. From what I understand from what is going on in usrp_prims_common.cc if the user specifies a path it should override the default one. Exactly how it formats this path I can't really keep track of and I think something is going wrong there. Under typical installations the path is constructed with /usr/local/share/usrp appended with rev2 or rev4 and the filename. If environment variable USRP_PATH is set, then the revision and filename are appended to that path instead. Read permissions are also checked before the path is returned. As you already suspect, the problem is most likely something minor. Try printing out the path in the find_file() call to see what you're searching for. Thomas I had it working on Ubuntu 9.04 x86 but it stopped working when I updated to 10.04. I tried reinstalling gnuradio 3.2 several times. And also tried the versions from synaptic but always came down with the same error. I've since wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 version of gnuradio but the problem continues. I do have usr/local/share/usrp/rev4/std.ihx and all that goes with it. I can also load the firmware with usrper and then put LED1 on and off so the USRP seems to be working correctly. I do get the feeling I'm missing something very obvious here because it seems the last instances of this sort of problem date back to 2007. Still I just can't put my finger on whats wrong. Any advice would be greatly appreciated. regards Craig ___ 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] Can't find firmware: std.ihx
On Wed, Jul 21, 2010 at 1:36 AM, Craig Tong tngcra...@rrsg.ee.uct.ac.za wrote: Hi, I'm having some trouble getting my USRP board running with just about any software. It always seems to die with Can't find firmware: std.ihx. I've tried a whole array of applications including usrp_fft.py and similar, usrp_probe and then also the C++ progs (test_usrp_standard_rx and the like). It dies with the same complaint when running the C++ software that we're busy writing. It fails on the line usrp_standard_rx::make( ... ) where the firmware file is specified. It is currently blank (i.e. default) but even if the file is specified explicitly, it still claims that it cannot be found. From what I understand from what is going on in usrp_prims_common.cc if the user specifies a path it should override the default one. Exactly how it formats this path I can't really keep track of and I think something is going wrong there. Under typical installations the path is constructed with /usr/local/share/usrp appended with rev2 or rev4 and the filename. If environment variable USRP_PATH is set, then the revision and filename are appended to that path instead. Read permissions are also checked before the path is returned. As you already suspect, the problem is most likely something minor. Try printing out the path in the find_file() call to see what you're searching for. Thomas I had it working on Ubuntu 9.04 x86 but it stopped working when I updated to 10.04. I tried reinstalling gnuradio 3.2 several times. And also tried the versions from synaptic but always came down with the same error. I've since wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 version of gnuradio but the problem continues. I do have usr/local/share/usrp/rev4/std.ihx and all that goes with it. I can also load the firmware with usrper and then put LED1 on and off so the USRP seems to be working correctly. I do get the feeling I'm missing something very obvious here because it seems the last instances of this sort of problem date back to 2007. Still I just can't put my finger on whats wrong. Any advice would be greatly appreciated. regards Craig ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP digital downconverters
On Fri, Jul 16, 2010 at 2:30 AM, bjoe...@ee.ethz.ch wrote: Hi, It sais, that the USRP digital downconverters have a programmable decimation rate. What does this decimation rate do? Is this the filter restricting the frequencies of the signal + noise? And how do I change this decimation rate? Decimation reduces the sample rate of the incoming sequence to a lower rate. You can find more information about the DDC on the wiki. http://gnuradio.org/redmine/wiki/1/UsrpFAQDDC How you set the decimation rate depends on how you use gnuradio. You may want to look at the following usrp interface file. usrp/host/include/usrp/usrp_standard.h Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about the channel distinguish when read from multi channel
On Sun, Jul 18, 2010 at 6:50 PM, John Wu jwjo...@gmail.com wrote: Hi all, I create a standard rx which contain 2 channels for two rx daughter board. Now I use read function read the sampled data, and deinterleave the data, but which channel is related to which daughter board, and the deinterleaved data is related to which channel? The interleaved data will come from the first DDC followed by the second. How the DDC's are connected to the ADC's will depend on the input mux setting. The exact default mux value escapes me at the moment, but I would assume that the channel for the board connected to the lower numbered ADC comes first. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] what is the different between usrp_prims_libusb0 and usrp_prims_libusb1?
They refer to version specific code for libusb (v0.1 or v1.0). Most of the code is made common between versions, but the remaining parts are in those files. Which file is compiled is determined by configure and will depend on your system setup. Thomas On 12/07/2010, John Wu jwjo...@gmail.com wrote: what is the different between usrp_prims_libusb0 and usrp_prims_libusb1? what case are they used? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Make error on Mandriva 2010.0
On Tue, Jun 29, 2010 at 9:46 AM, Monica Sit sit_mon...@yahoo.com wrote: Hi, I am trying to install gnuradio-3.2.2 on Linux Mandriva 2010.0 i586. The PC is a 32 bit Intel P4 machine. When I run the command './configure', all gnuradio components passed the configuration tests except [snip] libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/usrper usrper.o /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so -L/usr/lib -L/lib -lusb -lboost_thread-mt -lrt -pthread -Wl,-rpath -Wl,/usr/local/lib /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so: undefined reference to `libusb_clear_halt' /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so: undefined reference to `libusb_get_device_address' /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so: undefined reference to `libusb_close' /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so: undefined reference to `libusb_unref_device' /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so: undefined reference to `libusb_open' /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so: undefined reference to `libusb_claim_interface' /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so: undefined reference to `libusb_set_configuration' /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so: undefined reference to `libusb_free_device_list' /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so: undefined reference to `libusb_get_device_list' /home/user/gnuradio-3.2.2/usrp/host/lib/legacy/.libs/libusrp.so: undefined reference to `libusb_control_transfer' gnuradio 3.2.2 requires libusb-0.1 instead of the newer version 1.0 that you have installed. According to their wiki, Mandriva Linux 2010 only provides libusb-1.0 along with the compatibility layer for version 0.1 support. The latter does not work with gnuradio. You can either install (or build from source) the libusb-0.1 devel package or obtain a newer version of gnuradio from git that supports libusb-1.0. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_benchmark_usb.py failed max speed
On Tue, Jun 22, 2010 at 11:15 AM, jons...@eden.rutgers.edu wrote: Hello everyone, When I run usrp_benchmark_usb.py, the two fastest tests fail, leaving me with 8 MB/sec maximum. I have two questions: First, how do I get the 16MB and 32MB tests to pass? Do I need a faster CPU? Perhaps. What type of system are you running on? Restrictions on the USB bus may also cause issues. Second, supposing I can't get a faster system, what is the consequence of having a slower maximum speed? Just a smaller bandwidth during transmitting and receiving? usrp_benchmark_usb.py is not particularly reliable as a benchmark per se. But, in general, if your system can't keep up with the usrp then you'll lose packets. Reducing the bandwidth is one way to prevent that from happening. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FEC
On Tue, Jun 22, 2010 at 10:15 AM, Jakub Moskal jmos...@ece.neu.edu wrote: Hi, I'm using the digital/benchmark_*.py from the GIT repository and am getting a very low ratio of corrupt packets, usually under 0.5%. I use the default gmsk modulation, USRP1's with RFX2400 and run the benchmark with a frequency of 2.4G. Would this low ratio suggest that the FEC is being applied somewhere along the path, or not necessarily? I cannot find any piece of code which would prove it. Unless you made your own modifications, there is no FEC in the benchmark code. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 91, Issue 21
On Tue, Jun 22, 2010 at 12:28 PM, Tuan Ta ta.tu...@gmail.com wrote: Hi all, This question might be a little bit off-topic but going through the code on the transmission side, I didn't see CRC method got invoked anywhere. Though I did see that the CRC got removed and checked in the receiving side. I'd be grateful if anyone can give me a pointer. Have you looked at the make_packet() call? gnuradio-core/src/python/gnuradio/packet_utils.py Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Swig 2.0
On Thu, Jun 17, 2010 at 8:17 AM, Philip Balister phi...@balister.org wrote: I just noticed Swig 2.0 is out. Has anyone tried it with gnuradio yet? Philip I just tried it with a new build. I didn't notice any immediate differences. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 2 questions about packet size in USB and FPGA
On Mon, Jun 14, 2010 at 10:16 AM, Juan Quiroz asd...@yahoo.com wrote: Hi On the output path of the FPGA there's a FIFO, Is 512 byte the size of each packet stored in FIFO? If true, why do I have option for fusb_block_size = 1024? I think it would be better to send 512 byte packets instead of 1024 to avoid fragmentation The simple answer is buffering. The host controller transparently splits the transfer into appropriately sized packets, which are 512 bytes in this case. Whether it's better to use jumbo sized transfer blocks or more of a smaller size has more to do with the driver implementation on the host than the USB device. Thomas Thank's in advance Juan Quiroz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp mux question
2010/5/31 weizhongshan weizhongsha...@163.com: hello every ! i use one usrp to transmit complex gr_sin_wave,and use another two_channel usrp as the receiver. i thought the mux should be set to 32103210,but when i did this ,i got nothing but noisy .then i changed the mux to 33221100,i got the ecpected orthogonal sin and cos wave .that confuses me What is your daughterboard setup and why are you using 2 channels? With 2 channels, the default 32103210 value uses all four ADC's and the first 2 DDC's. It sounds like you only want to read one channel and output separated I and Q components. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Git commit for 3.2.2 release?
On Thu, May 20, 2010 at 5:29 PM, Catalin Patulea catalin.patu...@thinkrf.com wrote: Hi, I'm trying to create a patch that applies cleanly onto a 3.2.2 tarball. I would like to maintain my changes in the form of a Git branch. I can't seem to find a commit that matches up with the 3.2.2 release. The best I've been able to do is about 3000 lines of diff, which still feels quite big. Are the releases made from the git://gnuradio.org/gnuradio.git repo? Current releases - upcoming 3.3 - are generated out of the main git tree. Prior releases - such as 3.2.2 - were created from the former subversion repository. For a number of interoperability reasons, not every aspect of the old subversion repository exists in the git version. Notably, you won't find a specific commit that matches up perfectly with 3.2.2 or other releases because those changes were outside of svn trunk. For a different reason, I reconstructed the svn release history in git a few weeks back. The diff should be close to the 3.2.2 tarball. You may notice that the imported commits aren't particularly descriptive, which is one reason not to import them to git. http://github.com/ttsou/gnuradio-ttsou/tree/releases/3.2 The problem with this approach - or any method dependent on old, divergent branches - is that there will almost surely be conflicts if you plan on merging upstream. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Git commit for 3.2.2 release?
On Fri, May 21, 2010 at 2:59 PM, Catalin Patulea catalin.patu...@thinkrf.com wrote: On Fri, May 21, 2010 at 2:01 PM, Thomas Tsou tt...@vt.edu wrote: http://github.com/ttsou/gnuradio-ttsou/tree/releases/3.2 The best I've been able to find in there is 24d0fd9: http://github.com/ttsou/gnuradio-ttsou/commit/24d0fd908510846254f7317d353506c41daf079c This seems to have only SVN keywords-related diffs in common files, but there are a slew of files that are in one and not the other (the commit's tree vs 3.2.2 tarball). Yeah you're right. I only ran the diff against git/svn tracked files. The git commit and svn tag match, but there are other things going on with the tarball. Added build files make up part of the unaccounted changes, generated files another, and additional stuff that I can't explain. I think my best bet at the moment is to import a 3.2.2 tarball into my git repo and rebase on top of that? The reason we're stuck with 3.2.2 is that there's already an SRPM out there where we can add our changes as a distro-level patch. That could work. In either case, unless you're generating patches against tarball or repo only code sections, patches should apply to both version. Thomas The problem with this approach - or any method dependent on old, divergent branches - is that there will almost surely be conflicts if you plan on merging upstream. I can't wait for the 3.3 release! :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] old USRP inband code
On Thu, May 13, 2010 at 4:25 PM, George Nychis gnyc...@cmu.edu wrote: I'm trying to grab a copy of the GNU Radio code through git which still has the old USRP inband code. I noticed this commit from Jonathan in my search: Author: jcorgan jcor...@221aa14e-8319-0410-a670-987f0aec2ac5 Date: Thu Jul 9 02:55:51 2009 + Merged r11377:11390 from jcorgan/usrp-headers in to trunk. * Removed usrp-inband code from tree (put into limbo directory.) This code has become unmaintained and has started to suffer from bitrot. A checkpoint tag has been made for anyone still needing to use it: http://gnuradio.org/svn/gnuradio/tags/checkpoints/trunk-20090708-pre-usrp-reorg -- How I do get the tags with the current git structure? I'm struggling a bit with GIT :P Thanks a bunch. The can create a branch and reset to the state before the inband code was moved to limbo. Lets call it inband. git checkout -b inband git reset --hard eefb51c0c0fac68d Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re: [Discuss-gnuradio] PACKET FORMAT error
2010/5/11 zzw.1012 zzw.1...@163.com:
Hi, Thomas
thanks for your help ! you are right!
I add printf code in the function of usrp_basic.cc like this:
int usrp_basic_tx::write(const void *buf, int len, bool *underrun)
{
...
printf (len = %d\n, len);
if (len 0 || (len % 512) != 0)
{
fprintf(stderr, usrp_basic_tx::write: invalid length= %d\n, len);
}
}
then I run the example of benchmark_tx.py :
./benchmark_tx.py -f 2500M -s 1500 -M 0.001
it really send 194560 bytes = 190k for the default case using 4 samples per
symbol and it send 380k with -M 0.002.
but , I still have some question. first , after making packet with 1520
bytes, then whether is it going on gmsk(default) modulation? I think the
1520-bytes packet changes to 190kbytes occur in the process of gmsk. Is it
right? how to calculate the number from 1520 to 194560?
second, in the process of sending packet, the printf information as follow:
(./benchmark_tx.py -f 2500M -s 1500 -M 0.001)
len = 16384
len = 15872
len = 16384
len = 16384
len = 16384
len = 15872
len = 16384
len = 512
len = 16384
len = 16384
len = 16384
len = 16384
len = 14848
Is there have some discipline in sending data? I find it seems unorderly.
Most of these values will be dependent on the modulator. Using the
default settings, you have 8 bits per byte, 1 bit per symbol, 4
samples per symbol, and 4 bytes per sample (16-bit IQ).
The variability is due to the nature of streaming data and the
GNURadio runtime implementation. At the abstraction level going into
the usrp, there is no notion of fixed packet sizes or frame
boundaries, just samples. The repeated value you see of 16384 bytes is
related to the maximum size of transfer blocks in the underlying USB
layer.
Thomas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PACKET FORMAT error
On Sun, May 9, 2010 at 11:28 PM, zzw.1012 zzw.1...@163.com wrote:
Hi,
I'm studying benchmark_tx.py now. I find that the packet size is not
right (at least I'd like to think so) in the process of making packet, which
can be seen in pkt.py and packet_utils.py. In the packet consist of 2 bytes
packed_preamble, 8 bytes packed_access_code, 4 bytes header, 4 bytes
outband_crc with default 1500 bytes size, padding bytes and endbyte\x55 .
I use default gmsk modulatiom. So, the packet have 2 + 8 + 4 + 1504 + 1 + 1
= 1520bytes.
However, in the function of _npadding_bytes(pkt_bytes_len,
samples_per_symbol, bits_per_symbol) , there have such description:
generate sufficient padding such that each packet ultimately ends up being
a multiple of 512 bytes when sent across the USB, we send 4-byte samples
across the USB (16-bit I and 16-bit Q), thus we want to pad so that after
modulation the resulting packet is a multiple of 128 samples. Also , in the
function int usrp_basic_tx::write(const void *buf, int len, bool
*underrun)in the usrp_basic.cc, there have similar code like if (len 0
|| (len % 512) != 0){fprintf(stderr, usrp_basic_tx::write: invalid length
= %d\n, len}.
they both tell me that the data across the USB must be a multiple of 512
bytes .but in the example of benchmark_tx.py, the packet size is 1520
bytes. what's wrong ?
1520 bytes only refers to the packet size. The transmitted sample
stream at the physical layer includes a number of other factors
including conversion to bits, samples per symbol, and sample size. So
for the default case, a 1520 byte packet using 4 samples per symbol
yields 48640 samples or 194560 bytes, which is a multiple of 512.
Thomas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble in x86_64 land?
On Sat, May 8, 2010 at 6:09 PM, Marcus D. Leech mle...@ripnet.com wrote: I have a recent (couple of days old) GIT of Gnu Radio, installed on an x86_64 Quad-core QX9770. I have F12 installed on this, with all the updates applied. Any application that uses the wxGui sinks, using gl rendering, dumpeth the core, without even bringing a window up. Changing the rendering to nongl fixes the problem, but gosh, the nongl stuff is ugly, and doesn't have as many working features as the gl stuff. Has anyone else seen this issue? Anything that uses a gl scope type window seems to fail: One of my machines has this issue. I just assumed it was something with the ever changing Nouveau driver, which was included in F12. I haven't bothered with trying to get it to work. Are you running a nVidia card? My other 64-bit boxes are fine. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New trunk incompatible with old USRPs?
On Mon, May 3, 2010 at 7:57 PM, Vincenzo Pellegrini wwvi...@gmail.com wrote: Hi everybody, I have notice an oddity with recent trunks.. since I updated a couple of months ago, my USRP (#541) is not working any more with the current trunk. When I try to send out an 8MHz band, samples get consumed by the USRP slower than they are supposed to. This does not happen if I use old trunks with the #541 or either if I use the current trunk with a recent USRP. Has anybody been experiencing any such thing? When you mention old trunks, which git commit (or svn revision number) are you referring to? Or a release like 3.2.2? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] two doubts concerning WBX and **TX
On Mon, May 3, 2010 at 10:32 AM, Rafael Diniz raf...@riseup.net wrote: Hello people, I'd like to know if I can do some modification in the WBX to go as low as 26MHz, is it possible? If not, what is better - BasicTX or LFTX, and what kind of RF frontend should I use - amplifiers and what more? Is there any transmitter daughterboard that covers bands lower than 50MHz for the USRP? I'm certainly not the best person to explain daughterboard RF characteristics, but using a BasicTX I was able to generate an avalanche beacon signal, which operates at 457 kHz. With no added amplifier, it worked with a commercial transceiver up to a few meters. Depending on your transmit power needs, the BasicTX may suffice. I've never seen or used a LFTX, so I can't comment on it. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Benchmark ?
On Wed, Apr 28, 2010 at 1:59 AM, William Pretty Security Inc bill.pre...@xplornet.com wrote: Is there some bench mark I can run to test the USB and CPU loading ? Apparently there is a problem with usrp_benchmark_sub.py … Some basic tests for USRP operation. usrp_fft.py -d 8 usrp/host/apps/test_usrp_standard_rx usrp/host/apps/test_usrp_standard_rx usrp_benchmark_usb.py isn't really that effective as a benchmark per se, but can cause underlying issues to show up. In general though - embedded systems aside - USB isn't that much of a drag in overall CPU utilization on recent systems, which should be able to sustain 32MBps on the USB bus without much issue. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re: [Discuss-gnuradio] about tunnel.py
On Mon, Apr 26, 2010 at 8:57 PM, lishan...@126.com wrote: Thank you for you answer. Do you mean I can not achieve the goal by modifying its softare code beause of hardware restriction ? I have nothing to do except using more usrps?Thank you! You cannot use two instances to tunnel.py to create two network interfaces with a single usrp. One could, potentially, modify a single instance of tunnel.py to configure a single usrp with two daughterboards to support two network interfaces. I don't believe that this has ever been attempted though. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about tunnel.py
2010/4/26 lishan_wh lishan...@126.com: Hi all, I want to use tunnel.py to make a usrp with two daughter boards work as two pieces of wireless cards. The first time I run tunnel.py, it works well, and generate gr0. But when I run tunnel.py for the second time (in another terminal) to configure the other daughter board, it turned out error Unable to find usrp1. Is it possible to generate two wireless cards with only one usrp with two doughter boards instead of with two usrps? If it is, what should I do? No. At least not with the current implementation. The first run of tunnel.py opens up the usrp connection and any subsequent instances will fail since the usrp is already in use. The daughterboards are configured through the usrp interface, so you can't manipulate them independently from different programs. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] git commit for previous releases
On Sat, Apr 24, 2010 at 1:05 AM, Firas Abbas firasmail2...@yahoo.com wrote: http://gnuradio.org/redmine/wiki/gnuradio/DevelopingWithGit Perhaps I should rephrase my question. In git, I want to track changesets between the current development tree and previous *releases*. It turns out to be a silly question because the relevant commits don't exist in the git repo, which only carried over trunk from the old subversion tree. Thus, you won't find the commits if you search as they were in branches that only exist in svn world. So, to assemble the history that I was interested in, I cloned out of the svn repository and rebased the release branches at their respective original svn copy points. release-3.1 80e6a256ed352771acedbb2c5628d3d06f06a7d8 release-3.2 f64da1cf3acc3d12e3ac38f27cd3f09c3e920e0a The reconstructed histories are in my public repo. http://github.com/ttsou/gnuradio-ttsou/commits/releases/3.1 http://github.com/ttsou/gnuradio-ttsou/commits/releases/3.2 May another person who needs to travel back in time, with a fondness for git and distaste for svn, find this information useful. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] git commit for previous releases
Is it possible to find a git commit or svn revision number corresponding to previous GNU Radio releases? I'm working with some old driver code that was tested with release 3.1.3. The only tag I see if for 3.3git. Thanks. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] overrun problem on gr-sounder project
On Thu, Apr 22, 2010 at 4:38 PM, Yan Nie yn...@uwo.ca wrote: 2. How does the tune() function work? Does that tune the signal after ADC, by creating a analog daughterboard? or it tunes the signal on the LFRX daughterboard before ADC? I looked at the source and found the following. /*! * \brief High-level tune method. Works for the single channel case. * * This method adjusts both the daughterboard LO and the DDC so that * target_freq ends up at DC in the complex baseband samples. * * \param chan which DDC channel we're controlling (almost always 0). * \param dbthe daughterboard we're controlling. * \param target_freq the RF frequency we want at DC in the complex baseband. * \param[out] result details how the hardware was configured. * * \returns true iff everything was successful. */ Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp issue
On Fri, Apr 9, 2010 at 4:21 AM, voipas voi...@gmail.com wrote: Hello, Today the USRP stoped work at all. And we found the something wrong with power. Maybe due this issue, we had this problems. That's unfortunate. If the USRP stopped working entirely, the fuse (F501) may be blown. If you have an oscilloscope (or even a multimeter) nearby you can check if the power supply is doing anything strange. I've seen a few of them fail in various ways. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp issue
On Wed, Apr 7, 2010 at 8:03 AM, voipas voi...@gmail.com wrote: Hello, I've problem with USRP. Since I've upgraded my Ubuntu to 9.0.4 - usrp doesn't work: /usr/local/share/gnuradio/examples/usrp/usrp_benchmark_usb.py Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in type 'exceptions.AttributeError' ignored Testing 2MB/sec... usrp: failed to write fpga hash slot usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error Protocol error from USB generally indicates a low level error. Do you have any other USB devices attached (hubs, webcams, etc.)? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting a git revision number from an old subversion rev number
On Thu, Jan 21, 2010 at 12:43 PM, Ketan Mandke kman...@gmail.com wrote: Hi all, I have been using an old version of the gnuradio trunk. I wanted to check out that old version again, but I noticed that the switch over to git has been completed and the subversion repository has been taken down. Although, the git repository still looks like it has old versions of the code back to 2006. Is there any way to convert a revision number from the subversion repository into a git revision number? The subversion imported commits have the revision number at the end of the description in the git-svn-id line. For example, you can create and checkout a new branch with svn revision 10184 by doing the following. Find the commit hash from the git-svn-id. git log --grep=git-svn-i...@10184 Create and checkout a new branch named r10184 from the commit hash. git checkout -b r10184 cd7b07f0140ddff6 That works for me, and I'm sure there are other ways as well. Hope that helps. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 failing to load firmware
On Tue, Nov 24, 2009 at 10:32 AM, Philip Balister phi...@balister.org wrote: I running the latest gnuradio from git and see these messages when I run: usrper load_standard_bit [balis...@moose gnuradio]$ usrper load_standard_bits usrper: found unconfigured usrp; needs firmware. usb_control_msg failed: error sending control message: Protocol error write_cmd failed usb_control_msg failed: error sending control message: Protocol error write_cmd failed usb_control_msg failed: error sending control message: Protocol error write_cmd failed usb_control_msg failed: error sending control message: Protocol error write_cmd failed usb_control_msg failed: error sending control message: Protocol error write_cmd failed usb_control_msg failed: error sending control message: Protocol error write_cmd failed usb_control_msg failed: error sending control message: Protocol error write_cmd failed usrp: failed to load fpga bitstream /usr/local/share/usrp/rev4/std_2rxhb_2tx.rbf. usrper: failed The kernel is throwing -EPROTO, which, generally, is indicative of a low-level error with the HCI code. Can you try a different cable / usrp combination? I can't reproduce this error on any of my machines. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Assertion `dac_rate () == 128000000' failed.
On Mon, Nov 2, 2009 at 4:35 PM, Alexander Chemeris alexander.cheme...@gmail.com wrote: Thank you for information! I do hate this awkward heap, named git, so I'd better go with patches. No problem. I'm quite fond of git, but that discussion is for another time and place. To each their own. Hum, why branch GnuRadio if it works pretty nicely with OpenBTS? Because individual branches are routinely part of git development. Of course, that is not necessarily the case with other revision control systems. You mentioned future changes, so I was suggesting a branch to collect the current and any future re-clocking related patches. Right. But problem is that no python code (especially examples) don't set FPGA clock rate on start. So you either need to modify all python examples (ugh!) or provide a way to set default FPGA clock rate without touching any python files. One way I see is to pull default FPGA clock rate from environment. Ok, I see your point. As you know, the driver itself defaults to 64M, which is appropriate, and provides interfaces to change that value. IMO, that part should not change. One option is to set the clock rate information in the gr-usrp constructors. I agree that the examples should be left alone since they're not dependent on what the usrp is clocked at. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Assertion `dac_rate () == 128000000' failed.
On Sun, Nov 1, 2009 at 6:13 PM, Alexander Chemeris alexander.cheme...@gmail.com wrote: Could any of GnuRadio developers remove this assert? usrp_standard.cc:1024: virtual bool usrp_standard_tx::set_tx_freq(int, double): Assertion `dac_rate () == 12800' failed. It's no longer valid when you reclock your USRP and just makes it impossible to use libusrp in this case. Sounds reasonable to me. I'm now trying to make GnuRadio usable with OpenBTS without patching of GnuRadio and this is show-stopper for me now. PS Whom should I contact with more re-clocking related fixes? To date no Python examples seem to work with re-clocked USRP without patching. I'm seeking for a way to make them working without too much changes. Probably USRP FPGA frequency can be set from environment variable? Is there any nicer way to do this? Most gnuradio development occurs with git, so the easiest way to get changes accepted upstream is by generating patches against the master branch at: http://gnuradio.org/git/gnuradio.git master Patches or pull requests from a published repository clone can be submitted to the patch-gnuradio mailing list. I currently work with both openbts and gnuradio, so I can assist with host side re-clocking or git issues. I'm still getting setup on the hardware side, but as a start for testing I created an openbts branch in my repo at: git://github.com/ttsou/gnuradio-ttsou.git openbts Viewable at: http://github.com/ttsou/gnuradio-ttsou/tree/openbts For your last question, using the mid-level interfaces in usrp_basic may be more appropriate for your needs. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Fail to set RF frequency in certain range using Basic TX
On Tue, Oct 20, 2009 at 4:43 PM, George Lee georgel...@gmail.com wrote: When I tried to set the center frequency to 80M using Basic Tx board, the error message I got is as follows. I also tried some other frequency, from 70M - 84M , and had the same error. For most of the other frequency, it works fine. $ ./usrp_siggen.py --const -i 32 -f 80M usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled Using TX d'board A: Basic Tx Failed to set RF frequency Does anyone know the reason for this and how to solve this? Thank you very much. What version of gnuradio and operating system are you using? OSX? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb_darwin.cc compile fails on Mac OS X Snow Leopard with -arch x86_64
On Thu, Oct 8, 2009 at 5:19 PM, Jonathan P Jacky j...@u.washington.edu wrote: I am building from gnuradio-3.2.2.tar from Trac on an iMac9,1 with an Intel Core 2 Duo running Mac OS X 10.6.1 (Snow Leopard), XCode version 3.2, gcc version 4.2.1. I am following the directions at https://radioware.nd.edu/documentation/install-guides/mac-os-x and just got all the prerequisites from macports for this build. I am building one component at a time. I built gnuradio-core (but with one wrinkle - see PPS below). The build for usrp failed, in particular the compile for fusb_darwin.cc failed with these error messages, among others (full compile command with output appears in PPPS below): fusb_darwin.cc:348: error: cast from s_boths_buffer** to unsigned int loses precision fusb_darwin.cc:391: error: cast from void* to UInt32 loses precision ... etc. ... Both errors are coming from pointer casts to int types. Pointers and long types go to 8-bytes on 64-bit builds while int stays at 4-bytes on most systems. Using long rather than int types should fix things though I have no way test it out. Michael may be aware of other issues. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cygwin problems continue
On Mon, Sep 14, 2009 at 8:00 PM, Robert and Millie robert-and-mil...@cox.net wrote: python dial_tone.py Traceback (most recent call last): File dial_tone.py, line 23, in module from gnuradio import gr ImportError: No module named gnuradio This is where I am stuck. Any help would be gladly appreciated. Try the following before you run dial_tone. export PYTHONPATH=/usr/local/lib/python2.5/site-packages Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Package install problem on different computer.
On Tue, Sep 29, 2009 at 9:26 PM, Mir M. Ali mirmurt...@gmail.com wrote: Hi, I have a package with a few gnuradio modules that I developed. This package installs wihtout a hitch on my laptop. I then copied the package folder on to two ohter computers but the installation always fails. When doing 'make' it gives errors that I don't understand. Will someone help me on this. Thanks, Mir Do you have different versions of libtool installed on your computers? Try running bootstrap? Thomas The error is as shown below, make[1]: Entering directory `/home/mali/Documents/Thesis/dsss_gnuradio/config' make[2]: Entering directory `/home/mali/Documents/Thesis/dsss_gnuradio/config' make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/home/mali/Documents/Thesis/dsss_gnuradio/config' make[1]: Leaving directory `/home/mali/Documents/Thesis/dsss_gnuradio/config' Making install in src make[1]: Entering directory `/home/mali/Documents/Thesis/dsss_gnuradio/src' Making install in lib make[2]: Entering directory `/home/mali/Documents/Thesis/dsss_gnuradio/src/lib' make install-am make[3]: Entering directory `/home/mali/Documents/Thesis/dsss_gnuradio/src/lib' /bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include/gnuradio -I/usr/local/include/gnuradio/swig -I/usr/include/python2.5 -DOMNITHREAD_POSIX=1 -I/opt/boost_1_38_0/include/boost-1_38 -I/usr/local/include/gnuradio -I/usr/local/include -g -O1 -Wno-strict-aliasing -Wno-parentheses -g -O2 -Wall -Woverloaded-virtual -MT _dsss_la-dsss.lo -MD -MP -MF .deps/_dsss_la-dsss.Tpo -c -o _dsss_la-dsss.lo `test -f 'dsss.cc' || echo './'`dsss.cc ../../libtool: line 847: X--tag=CXX: command not found ../../libtool: line 880: libtool: ignoring unknown tag : command not found ../../libtool: line 847: X--mode=compile: command not found ../../libtool: line 1014: *** Warning: inferring the mode of operation is deprecated.: command not found ../../libtool: line 1015: *** Future versions of Libtool will require --mode=MODE be specified.: command not found ../../libtool: line 1158: Xg++: command not found ../../libtool: line 1158: X-DHAVE_CONFIG_H: command not found ../../libtool: line 1158: X-I.: command not found ../../libtool: line 1158: X-I../..: No such file or directory ../../libtool: line 1158: X-I/usr/local/include/gnuradio: No such file or directory ../../libtool: line 1158: X-I/usr/local/include/gnuradio/swig: No such file or directory ../../libtool: line 1158: X-I/usr/include/python2.5: No such file or directory ../../libtool: line 1158: X-DOMNITHREAD_POSIX=1: command not found ../../libtool: line 1158: X-I/opt/boost_1_38_0/include/boost-1_38: No such file or directory ../../libtool: line 1158: X-I/usr/local/include/gnuradio: No such file or directory ../../libtool: line 1158: X-I/usr/local/include: No such file or directory ../../libtool: line 1158: X-g: command not found ../../libtool: line 1158: X-O1: command not found ../../libtool: line 1158: X-Wno-strict-aliasing: command not found ../../libtool: line 1158: X-Wno-parentheses: command not found ../../libtool: line 1158: X-g: command not found ../../libtool: line 1158: X-O2: command not found ../../libtool: line 1158: X-Wall: command not found ../../libtool: line 1158: X-Woverloaded-virtual: command not found ../../libtool: line 1158: X-MT: command not found ../../libtool: line 1158: X_dsss_la-dsss.lo: command not found ../../libtool: line 1158: X-MD: command not found ../../libtool: line 1158: X-MP: command not found ../../libtool: line 1158: X-MF: command not found ../../libtool: line 1158: X.deps/_dsss_la-dsss.Tpo: No such file or directory ../../libtool: line 1158: X-c: command not found ../../libtool: line 1211: X_dsss_la-dsss.lo: command not found ../../libtool: line 1216: libtool: compile: cannot determine name of library object from `': command not found make[3]: *** [_dsss_la-dsss.lo] Error 1 make[3]: Leaving directory `/home/mali/Documents/Thesis/dsss_gnuradio/src/lib' make[2]: *** [install] Error 2 make[2]: Leaving directory `/home/mali/Documents/Thesis/dsss_gnuradio/src/lib' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/mali/Documents/Thesis/dsss_gnuradio/src' make: *** [install-recursive] Error 1 m...@wcdaigle-desktop:~/Documents/Thesis/dsss_gnuradio$ sudo make make all-recursive make[1]: Entering directory `/home/mali/Documents/Thesis/dsss_gnuradio' Making all in config make[2]: Entering directory `/home/mali/Documents/Thesis/dsss_gnuradio/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/mali/Documents/Thesis/dsss_gnuradio/config' Making all in src make[2]: Entering directory `/home/mali/Documents/Thesis/dsss_gnuradio/src' Making all in lib make[3]: Entering directory `/home/mali/Documents/Thesis/dsss_gnuradio/src/lib' make
Re: [Discuss-gnuradio] One question regarding -B FUSB_BLOCK_SIZE and -N FUSB_NBLOCKS
On Mon, Sep 28, 2009 at 1:50 PM, Bishal Thapa bdarealt...@gmail.com wrote: Dear Tim, First of all, thanks for your time answering my question. Secondly, one point you left out is: I am sending 104*128 bytes in reality, because I am spreading a packet of size 128 bytes with a 104 bits long spreading sequence right inside the pkt.py file in the gnuradio-core/src/python/gnuradio/blk2imp/pkt.py location. Does not that mean I am not running into the USB block-size issue? I do not believe you are running into USB block size issues. By default, the Linux usrp implementation will submit to the kernel all data passed to it in the write call. Lastly, question to the list and for Tim also, what does -N and -B options in ./benchmark_tx.py script represent? It says it is the block size for fast usb option and number of fast usb blocks in the description, what does this mean? Please help me understand. Thank you. Loosely speaking, FUSB_BLOCK_SIZE and FUSB_NBLOCKS refer to the individual size and number of outstanding asynchronous transfers that can be submitted to the underlying USB interface. The defaults (specified with 0) use operating system dependent values. For example, for Linux the default block size is 16-kb, which is then broken up by the kernel into 512-bytes payloads that are sent over the hi-speed USB bus. Other combinations are possible. These include values less than or non-multiples of 512-bytes, but this results in poor use of limited USB bandwidth and ineffective use of existing code based around 512-byte payloads. For most general use cases, the default values should suffice. Hope that helps. -- Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packet mod/demod race condition?
Hi Steven, If I uncomment the sleep, I never see this message. So: Q1) Any idea what this error is all about? Is this a race condition that needs to be addressed, or am I doing something wrong? This part I'm not sure about. Q2) The original audio file is 350.0KB. Sometimes the resulting audio file is complete, other times it never gets the last few KB (ends up 341.0KB, for example). How do I ensure that all the bytes make it across successfully? The benchmark loopback code makes no guarantee of delivery. In order to do so, you need some method or higher level protocol to detect and retransmit any dropped frames. Though in your case, I wouldn't expect the received file to vary per run. Again, I'm not sure here. Q3) What is the effect of packet size? Is there an optimum size? A max size? For USRP, packets need to be padded to a multiple of XXX? The optimal size depends on the given application. Latency and overhead might be two considerations. The max packet size is limited by the length of the whitener PN sequence. I don't believe there are any restrictions beyond that. The USRP will view the data in a stream form; it won't have any notion of the data packet length at that point. Q4) Some examples use gr.enable_realtime_scheduling(). What is the effect of this, and do I need it? I note that it requires a sudo. Realtime scheduling changes the scheduling policy of selected threads to a priority over normal threads. In Linux, root access is required in order to do so. It should result in more lower latencies and more deterministic behavior. Thanks for your time! -Steven Anytime. -TT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GMSK demodulation
On 8/23/07, Jeffrey Karrels [EMAIL PROTECTED] wrote: Hello all i am looking at gmsk again. i had two questions come up. 1) does clock recovery normally take place after fm demod? Sure. 2) what clock recovery algo would one normally find in a receiver like a GSM receiver? MM, Gardner, wired clocks... You're going to have to be more specific here. thanks jeff -TT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Weird Behavior of BPSK on RFX 2400
In the clock recovery, the useful term in the output of the MM error detector becomes small for long sequences of identical symbols. This affects the sampling instant, and I suspect is related to what you are seeing. You can modify the gain_mu value to get these and similar effects. -TT On 8/13/07, Shyamnath [EMAIL PROTECTED] wrote: Hi guys, I am trying to analyze the functionality of each of the blocks in the dbpsk mod/demod when I noticed the following behavior. The high level modulator flow control is as | Symbols |- | RRC filter | - |amplifier | - channel and that for the demodulator is channel - | Pre-scaler| - |agc| - |RRC | - |clock recovery| - |slicer| My understanding is that the real part of the output of the clock recovery must be close to that of the symbols or some scaled version of it(+a, -a in case of bpsk). However, my observations (in the link below) show that the output of the clock recovery depends a lot on the bit pattern, i.e., for the bit pattern 1010 the peaks of the 1s and the 0s are way smaller than those of the bit pattern 11. http://nms.csail.mit.edu/~gshyam/data/clock.pdf Since we are using a RRC I would doubt it is due to ISI . and since the radios are close to each other and there is a direct LOS I donot think this is due to multi-path (or is it?). Is this behavior due to some component on RFX 2400/USRP or something else? thanks Shyam -- View this message in context: http://www.nabble.com/Weird-Behavior-of-BPSK-on-RFX-2400-tf4264711.html#a12137123 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Upgrade to Fedora 7?
I used FC7 since the day of and prior to it's release. I've had a number of issues, but none of them regarding GNU Radio. -TT On 8/8/07, Trond Danielsen [EMAIL PROTECTED] wrote: 2007/8/8, [EMAIL PROTECTED] [EMAIL PROTECTED]: I've been using Ubuntu with much better results. You'll spend less time fixing the OS and more time on doing GNU radio stuff. On Tue, 7 Aug 2007, Marcus Leech wrote: I'm considering upgrading my receiver 'puter (a Dual-core Pentium system) from FC6 to Fedora7. Anything I need to know for Gnu Radio? I've been using both FC6 and F7 with GNU Radio, and have never had any problems. I've already noticed that Firefox 2.0.0.5 is *very* flakey on Fedora 7--crashes without provocation every few minutes. [If anyone here happens to know the fix for that, that would be cool, but I'm mostly interested in Gnu Radio gotchas]. I am using FF 2.0.0.5, and cannot find any problems with it. I leave it running for days on my workstation, and it does not crash here. -- Trond Danielsen ___ 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
