Re: [Discuss-gnuradio] OSX UHD runtime troubles
On 12/02/2012, at 10:48, Peter Jensen wrote: > I had similar symptoms with my OSX Lion machine and macports-built > dependencies. In my case, I was using the macports Python 2.6, but > pmt_swig.so was linked against the OSX-provided Python 2.7 library, unlike > everything else which was properly linked against the /opt/local macports > python 2.6. > > The cmake command line that got it working for me was: > cmake .. > -DPYTHON_LIBRARY=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/libpython2.6.dylib > > -DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 > > In that case I'm not specifying the python executable because the proper one > was first in the path. I don't know if this is exactly your problem, but it's > definitely worth thinking through the library deps to make sure you are not > mixing python installations up. > > In your case I am suspicious of the > "/System/Library/Frameworks/Python.framework/Versions/2.7/Python" dependency > when everything else is pointing to /opt/local. Ah that's a good point.. I had assumed that MacPorts installed that, however I see that it installs elsewhere. I re-cmake'd with.. cmake .. -DPYTHON_LIBRARY=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib -DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 and now it works, thanks! I can't actually test it with hardware yet but it's progress :) > -Peter > > On 02/11/2012 06:12 PM, Daniel O'Connor wrote: >> Hi, >> I'm trying to build and run GNURadio on OSX Lion (with MacPorts) but I am >> having trouble with UHD. >> >> I've built and install GNURadio (from git) however when I run anything the >> Python interpreter crashes like so.. >> In [1]: import gnuradio.uhd >> Mac OS; GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >> 2335.15.00); Boost_104800; UHD_003.004.000-122b947 >> >> Fatal Python error: Interpreter not initialized (version mismatch?) >> >> Since I initially got UHD as a binary I uninstalled it then built it from >> the sources but I get the same problem. >> >> Running 'ccmake' shows the Python path as /opt/local/bin as I expect. >> >> The stack trace and binary image list look like so.. >> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >> 0 libsystem_kernel.dylib 0x7fff8bd5982a __kill + 10 >> 1 libsystem_c.dylib0x7fff892b6a9c abort + 177 >> 2 org.python.python0x0001035b196e Py_FatalError + 49 >> 3 org.python.python0x0001035af46b Py_InitModule4_64 + >> 74 >> 4 _uhd_swig.so 0x000103472b8f init_uhd_swig + 543 >> 5 org.python.python0x000102fce1aa >> _PyImport_LoadDynamicModule + 170 >> 6 org.python.python0x000102fcaae5 imp_load_module + 341 >> 7 org.python.python0x000102fb4a7b PyEval_EvalFrameEx + >> 18011 >> 8 org.python.python0x000102fb7e13 fast_function + 179 >> 9 org.python.python0x000102fb4b2d PyEval_EvalFrameEx + >> 18189 >> 10 org.python.python0x000102fb7cd7 PyEval_EvalCodeEx + >> 2103 >> 11 org.python.python0x000102fb7d56 PyEval_EvalCode + 54 >> 12 org.python.python0x000102fcb123 >> PyImport_ExecCodeModuleEx + 243 >> 13 org.python.python0x000102fcb796 load_source_module + >> 1462 >> 14 org.python.python0x000102fcc763 import_submodule + >> 467 >> 15 org.python.python0x000102fcc97b load_next + 251 >> 16 org.python.python0x000102fcd7d0 >> PyImport_ImportModuleLevel + 1184 >> 17 org.python.python0x000102faadf4 builtin___import__ + >> 132 >> 18 org.python.python0x000102f1cae1 PyObject_Call + 97 >> 19 org.python.python0x000102faf824 >> PyEval_CallObjectWithKeywords + 180 >> 20 org.python.python0x000102fb6746 PyEval_EvalFrameEx + >> 25382 >> 21 org.python.python0x000102fb7cd7 PyEval_EvalCodeEx + >> 2103 >> 22 org.python.python0x000102fb7e88 fast_function + 296 >> 23 org.python.python0x000102fb4b2d PyEval_EvalFrameEx + >> 18189 >> 24 org.python.python0x000102f
[Discuss-gnuradio] OSX UHD runtime troubles
;712AAEAC-AD90-37F7-B71F-293FF8AE8723> /usr/lib/system/libdispatch.dylib 0x7fff8342b000 - 0x7fff83431fff libmacho.dylib (800.0.0 - compatibility 1.0.0) /usr/lib/system/libmacho.dylib 0x7fff84cf2000 - 0x7fff84cf7fff libcache.dylib (47.0.0 - compatibility 1.0.0) /usr/lib/system/libcache.dylib 0x7fff85231000 - 0x7fff85239fff libsystem_dnssd.dylib (??? - ???) <7749128E-D0C5-3832-861C-BC9913F774FA> /usr/lib/system/libsystem_dnssd.dylib 0x7fff87c29000 - 0x7fff87dfdfff com.apple.CoreFoundation (6.7.1 - 635.19) <57B77925-9065-38C9-A05B-02F4F9ED007C> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff87e5d000 - 0x7fff87e5efff libdnsinfo.dylib (395.6.0 - compatibility 1.0.0) <718A135F-6349-354A-85D5-430B128EFD57> /usr/lib/system/libdnsinfo.dylib 0x7fff87ff5000 - 0x7fff8806aff7 libc++.1.dylib (19.0.0 - compatibility 1.0.0) /usr/lib/libc++.1.dylib 0x7fff88134000 - 0x7fff8813aff7 libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib 0x7fff8813b000 - 0x7fff8813 libdyld.dylib (195.5.0 - compatibility 1.0.0) /usr/lib/system/libdyld.dylib 0x7fff8000 - 0x7fff88892ff7 liblaunch.dylib (392.18.0 - compatibility 1.0.0) <39EF04F2-7F0C-3435-B785-BF283727FFBD> /usr/lib/system/liblaunch.dylib 0x7fff89275000 - 0x7fff89352fef libsystem_c.dylib (763.12.0 - compatibility 1.0.0) /usr/lib/system/libsystem_c.dylib 0x7fff8941d000 - 0x7fff8941efff libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff8941f000 - 0x7fff8941 libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib 0x7fff89437000 - 0x7fff894aafff libstdc++.6.dylib (52.0.0 - compatibility 7.0.0) <6BDD43E4-A4B1-379E-9ED5-8C713653DFF2> /usr/lib/libstdc++.6.dylib 0x7fff894d7000 - 0x7fff895bbe5f libobjc.A.dylib (228.0.0 - compatibility 1.0.0) <871E688B-CF57-3BC7-80D6-F6476DFF109B> /usr/lib/libobjc.A.dylib 0x7fff89c8e000 - 0x7fff89e90fff libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <38CD6ED3-C8E4-3CCD-89AC-9C3198803101> /usr/lib/libicucore.A.dylib 0x7fff8a071000 - 0x7fff8a075fff libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) /usr/lib/system/libmathCommon.A.dylib 0x7fff8a757000 - 0x7fff8a769ff7 libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib 0x7fff8b8de000 - 0x7fff8b8e3ff7 libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib 0x7fff8b92c000 - 0x7fff8b959fe7 libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <095FDD3C-3961-3865-A59B-A5B0A4B8B923> /usr/lib/libSystem.B.dylib 0x7fff8bd43000 - 0x7fff8bd63fff libsystem_kernel.dylib (1699.22.73 - compatibility 1.0.0) <69F2F501-72D8-3B3B-8357-F4418B3E1348> /usr/lib/system/libsystem_kernel.dylib 0x7fff8c5c2000 - 0x7fff8c610fff libauto.dylib (??? - ???) /usr/lib/libauto.dylib 0x7fff8c611000 - 0x7fff8c612ff7 libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib 0x7fff8c613000 - 0x7fff8c61eff7 libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib 0x7fff8c642000 - 0x7fff8c684ff7 libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) /usr/lib/system/libcommonCrypto.dylib 0x7fff8cc57000 - 0x7fff8cc92fff libsystem_info.dylib (??? - ???) <35F90252-2AE1-32C5-8D34-782C614D9639> /usr/lib/system/libsystem_info.dylib 0x7fff8daf3000 - 0x7fff8daf4ff7 libremovefile.dylib (21.1.0 - compatibility 1.0.0) <739E6C83-AA52-3C6C-A680-B37FE2888A04> /usr/lib/system/libremovefile.dylib 0x7fff8e5e5000 - 0x7fff8e5e6fff libunc.dylib (24.0.0 - compatibility 1.0.0) /usr/lib/system/libunc.dylib 0x7fff8ed4 - 0x7fff8ed41ff7 libsystem_sandbox.dylib (??? - ???) <5087ADAD-D34D-3844-9D04-AFF93CED3D92> /usr/lib/system/libsystem_sandbox.dylib 0x7fff8f068000 - 0x7fff8f071ff7 libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) /usr/lib/system/libsystem_notify.dylib Any help appreciated, thanks :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gigabit Ethernet cards
On 09/07/2010, at 1:31, Marcus D. Leech wrote: > On 07/08/2010 11:50 AM, Lamar Owen wrote: >> Since you said PCI, I'm assuming this isn't a PCI Express box we're talking >> about here, since that changes everything. A single lane PCI-e slot is >> capable of 250MB/s throughput, if the chipset can keep up. Typical server >> GigE cards for PCI-e can have two or four ports and need a four lane slot; >> if you have dual PCI-e x16 slots, use the secondary x16 slot in x4 mode. >> >> >> > I have a PCIe x16 slot on the mobo, it's a GigaByte GA-880GM-UD2H, so I > guess what I really need is a > PCIe GiGE card. I use this http://www.newegg.com/Product/Product.aspx?Item=N82E16833106033 in my home (FreeBSD) server. (When I ordered it it came with full height and LP plates but I didn't get it from Newegg so YMMV) Never used it with a USRP2 though, however Intel em cards are widely regarded as being very good. If you really did mean PCI instead of PCI express then I think I had one of these in an older server.. http://www.newegg.com/Product/Product.aspx?Item=N82E16833106122&Tpk=PWLA8391GTLBLK It was also an excellent performer. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is it possible to change ADC/DAC rates?
On Wed, 24 Jun 2009, Colby Boyer wrote: > Say from 100MHz to 88MHz? Have you purchased a flux capacitor from Ebay? :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Marvell Yukon 88E8039 PCI-E Ethernet - USRP2
On Wednesday 31 December 2008 02:37:37 Eric Blossom wrote: > Google tells me that the Marvell Yukon 88E8039 PCI-E Ethernet > controller is a "Fast Ethernet" card; that is 100Mbit, not 1000Mbit. > > The USRP2 requires gigabit ethernet. The 'msk' man page in FreeBSD says it's GigE. Maybe it's not negotiating properly though.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Intel Atom is NICE.
On Monday 29 December 2008 21:41:03 Bob McGwier wrote: > The intel graphics chip set and northbridge are power hungry. I think the > idea is optimize code for the 330 and not the peripherals with this I think that unfortunately the power consumption is high regardless of wether you actually use the video or not :( > inexpensive and easy to use Mobo. The disk drive is hungry as well. Well you could use an SSD ;) > One does NOT need to spend thousands of dollars on an SDR computer for most > operations. That is a convenient excuse for me to justify my computer I think the Athlon would be quite competitive, it has higher memory bandwidth I believe and the boards aren't limited in connectivity like the Atom. Basically my point was that it should be considered rather than just assuming the Atom is best :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Intel Atom is NICE.
On Monday 29 December 2008 06:53:30 Bob McGwier wrote: > I am running GnuRadio, SDRMAX, and PowerSDR on my new Intel ATOM 330 > MiniITX motherboard. I had to put a firewire card in the single PCI slot. > The integrated intel graphics are nice and spiffy (glxgears is at 800 fps > if you turn off the desktop enhancements, no wiggly windows please). > > > > At 96000 PowerSDR is running under 15% CPU. The ATOM burns EIGHT watts and > has dual hyperthread cores (shows up as four processors in task manager). Unfortunately the 945 chipset eats ~20W - god knows why Intel lumbered the Atom with it :( Toms Hardware (and others) did a test of the Atom vs an underclocked Athlon and the later won most of the tests http://www.tomshardware.com/reviews/Atom-Athlon-Efficient,1997-1.html I think the Atom combo is cheaper and smaller though :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] testing outside building with our USRPs
On Tuesday 02 December 2008 13:23:49 Bill Stevenson wrote: > Thank you for your information about the laptop power rig. But our problem > is we have to use eight USRPs as our nodes in our experimentation, and we > do not have so many laptops, so do you know how to get 110-220 voltage > input for our computers when testing outside? Thank you! You could parallel up a few car batteries and run the PCs off an inverter. The power requirements are variable depending on your PCs of course :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 SD Card rewrite
On Monday 03 November 2008 10:31:59 Robert McGwier wrote: > with the rest which I emphasize again. If you get the wrong for > the device, you can wipe out your hard drive. Most people will have > their hard drive as /dev/sda and on my computer it seems the device > is, like Matt's computer, to be /dev/sdb. Surely the kernel would prevent you writing to a disk that is opened by it for the FS. (It does in FreeBSD anyway) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A Verilog question or two
On Thursday 16 October 2008 01:00:19 Jason Uher wrote: > 2008/10/14 Daniel O'Connor <[EMAIL PROTECTED]>: > > On Wednesday 15 October 2008 01:15:48 Sebastiaan Heunis wrote: > >> always @(posedge clk) > >> begin > >> tap1 <= #1 input; > >> tap2 <= #1 tap1; > >> tap3 <= #1 tap2; > >> end > >> > >> the #1 ensures that tap1 gets updated before tap2? > > > > According to what I have read with about synthesis tools the delays will > > be ignored totally. > > > > I see a lot of it though, so I don't know if it's superstition or the > > manual lies. > > I think the delays are just for simulation. In synthesis the > assignments take a real amount of time to complete (because it's > hardware). If you are dependent on that delay, you need to signify > that in simulation, otherwise the assignment would occur at the same > simulation timestep as everything else and you could be using new data > instead of old. Most likely synthesis ignores them, but they are > needed for the simulation (I'm not 100% sure, I usually remove all > such delays before synthesis testing). Hmm.. I think it's more likely to be superstition for broken simulators then.. A book I have (Kilts - Advanced FPGA design) states that "Delays are always ignored by synthesis tools, and this type of modeling can easily create mismatches between simulation and synthesis." (page 167). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A Verilog question or two
On Wednesday 15 October 2008 01:15:48 Sebastiaan Heunis wrote: > always @(posedge clk) > begin > tap1 <= #1 input; > tap2 <= #1 tap1; > tap3 <= #1 tap2; > end > > the #1 ensures that tap1 gets updated before tap2? According to what I have read with about synthesis tools the delays will be ignored totally. I see a lot of it though, so I don't know if it's superstition or the manual lies. The above code will do those 3 assignments simultaneously. I found the following to be very very useful in explaining things in detail without getting bogged down in the useless level of crud you find in a lot of text books (eg how CMOS gates are made..) http://web.mit.edu/6.111/www/f2005/ > And the last question is regarding the assign statement. I know that > when we have commands inside a always @(posedge clk) block, we look at > clock changes and do certain things. Do we use the assign statement > if we for instance want to change an output when in input changes or > if we have an output that is not dependent on a clock? I still don't > exactly know when to use an assign instead if putting it inside an > always block? What's the rule of thumb? always @(posedge clk) will only cause things to change on the positive edge of clk (like it says :) - using assign will cause things to change at any time. (sequential vs combinational). You can also do combinational logic inside an always block (see page 5 onwards of L04 above). PS I am far from a Verilog guru so if there is one reading please correct any mistakes I have made :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] powerline PHYs?
On Fri, 3 Oct 2008, Simon Knight wrote: > I agree with Jim. > It's stating the obvious unless you're an electrician this could be > very dangerous. There are out of the box powerline ethernet adapters you could build into a device with minimal risk. You can even get access points which have a powerline port (quite a neat way of adding wireless to a house IMO). The only down side is they are fairly pricey. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio mention in DEFCON subway presentation
On Tue, 12 Aug 2008, Dan Halperin wrote: > On Aug 11, 2008, at 4:58 PM, Daniel O'Connor wrote: > > On Mon, 11 Aug 2008, Philip Balister wrote: > >> New appication for USRP+GNU radio, free subway rides :) > >> > >> http://www-tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf > >> > >> Well, at least until people learn to deploy secure systems. > > > > There's also.. > > http://venturebeat.com/2008/08/08/defcon-excuse-me-while-i-turn-off > >-your-pacemaker/ > > > > A bit more scary :( > > Please please please don't be scared by this. Yet :). We believe that > the risk to patients with today's technology is basically nil. Our > attacks took tens of seconds to minutes and required very close > range. From there it's much easier just to punch you. Well, I don't have a pacemaker so punching would be your only method ;) The range issue could be 'improved' with a better antenna though, right? > The sentence that the article misquotes was closer to "With today's > hardware, these attacks are mostly academic. We need to develop > effective security solutions now before these types of attacks become > easier to mount." > > If I needed a pacemaker/cardiac defibrillator, I would get one > without hesitation -- including the model we investigated. Maybe you could start wearing chainmail ;) It certainly looks like it was an interesting project :) Do you have a paper on it? I had a google but the top hits are "ZOMG HACKERS WILL KILL US ALL" :-/ -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio mention in DEFCON subway presentation
On Mon, 11 Aug 2008, Philip Balister wrote: > New appication for USRP+GNU radio, free subway rides :) > > http://www-tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf > > Well, at least until people learn to deploy secure systems. There's also.. http://venturebeat.com/2008/08/08/defcon-excuse-me-while-i-turn-off-your-pacemaker/ A bit more scary :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] US no-license for USRP info?
On Mon, 30 Jun 2008, Clark Pope wrote: > Does anyone know what the export situation is for the USRP? Seems to > me even in receive only mode their must be some objective criterion > (tune range, speed, bandwidth, etc.) that determines whether usrp can > or cannot be exported? Also, since the usrp is being used in > government/military applications, why doesn't ITAR apply to it? ISTR it comes down to digitiser speed & bit width and computing power. The USRP isn't particularly great in either regard (no offense intended :) so I don't think it would be an issue.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new 802.11b receiver
On Wed, 2 Apr 2008, Matt Ettus wrote: > 100 mbps ethernet -- works, but very little testing done on it. 10 > mbps ethernet probably works too, but no testing has been done. > > PoE is not in there at this time. It was a question of development > time, not of going over the PoE power limits. I imagine it would be pretty easy to get a separate PoE box (eg http://www.dlink.com/products/?sec=0&pid=332) and sitting that in front if you need it anyway (you might need another regulation stage unless the regulator on the USRP2 will take 12V. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 JTAG functionality [was Exposing more JTAG functionallity in FX2firmware]
On Tue, 1 Apr 2008, Jeff Brower wrote: > This reminds me of a question I have about USRP2. My understanding > is the USRP2 has a Xilinx Spartan 3, which I don't think come in > anything other than BGA packages. Hopefully Matt brought the JTAG Actually they do come in other packages, VQ100, TQ144 & PQ208 although you are limited to an XC3S400 and of course correspondingly less IOs. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ISE Project navigator and ISE files
On Wed, 16 Jan 2008, Eric Blossom wrote: > > In my experience this doesn't work very well - project navigator > > touches it everytime you do just about everything. Also I've had PN > > crash when you open an ise file from another platform. It also has > > a tendency to corrupt it and recreating it by hand sucks. > > > > To work around this I have a script that uses the 'pjcli' tool, it > > looks like this.. > > Daniel, we'd love to have a better solution. We're using 9.2.04i. > Can you create what ever this script is and tell how to use it? On a > related topic, we were wondering if you really can run the xilinx I found about it when I asked Xilinx tech support. The only commands in it I'm aware of are the ones I've listed below although you can infer parameters from PN. I normally use 8.2 but I did try it with 9.2 when I was testing something and it seemed to work fine. I normally run it under FreeBSD and 9.2 has issues with the emulation. > tools from a Makefile and get access to all of the options that are > available in ISE. In looking at the tcl log, it appears that it's > passing most of the options by way of the .ise binary blob. I believe you can do it - I did start writing one but I ran into difficulties with simulation. I don't have ModelSim and I couldn't get iverilog or cver to grok my code (I use Coregen cores and they don't like them). I have found a few links you might be interested in WRT makefiles.. http://www.dilloneng.com/documents/downloads/gen_ise_sh/ http://www.xess.com/appnotes/makefile.html Also if you want to use Impact in Linux then you can use this http://rmdir.de/~michael/xilinx/ (I'd like to build a Linux libusb that works with FreeBSD's USB subsystem one day :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ISE Project navigator and ISE files
Hi, I had a look around the SVN repo when the most recent USRP announcement was made and I noticed that the .ise project file has been committed. In my experience this doesn't work very well - project navigator touches it everytime you do just about everything. Also I've had PN crash when you open an ise file from another platform. It also has a tendency to corrupt it and recreating it by hand sucks. To work around this I have a script that uses the 'pjcli' tool, it looks like this.. # Create the project NewProject(foo.ise) # Set basic properties SetProperty(Device Family, spartan3) SetProperty(Device, xc3s400) SetProperty(Package, tq144) SetProperty(Speed Grade, -4) SetProperty(Top-Level Module Type, HDL) # Add the sources AddSource(foo.v, Verilog Design File) AddSource(foo.ucf, foo) AddSource(alu.xco, Coregen Design File) AddSource(alu_wrap.v, Verilog Design File) # Test bench sources AddSource(foo_test.v, Verilog Design File) SetProperty(Simulation Run Time, 5000 ns, foo_test_v, Simulate Post-Place & Route Model, 9, foo) # Close the project to tidy up CloseProject() To use it you run.. pjcli -f foo.npl -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] the best file system for reading fast
On Wed, 5 Sep 2007, Jim Perkins wrote: > For the absolute best performance put the recording partition at the > front of the disk. The beginning of the disk is much faster than the > end. I've tested recent SATA drives at over 60 MB/s at the beginning > of the disk. Toward the end of the disk the performance can drop > below 30 MB/s. As and example suppose your drive is 500 GB. Make > the first partition 50 GB and the second 450 GB. Use the first > partition as the recording partition and the second for storage and > whatever. At 32 MB/s the 50 GB partition will hold 26 minutes of > continuous data. This is obviously a "purist" approach but doing it > this way you will have a RELIABLE recording setup. I would suggest you use a completely separate disk then you won't have problems with random seeks stuffing you up. You might want to consider higher performance disks too (although ISTR 10k & 15k RPM disks don't get [much] more sequential throughput). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] makefiles trouble
On Tue, 7 Aug 2007, Hans Glitsch wrote: > Please help me. I'm having a lot of trouble understanding the make > files to build gnuradio and the makefiles I use to build my own > gnuradio blocks. Also, swig hates me and I hate it. So far I've had > no trouble building gnuradio and building my own blocks by delicately > modifying an example build tree, but now I want to do something a > little different. Please don't just follow up to a random thread and change the subject to something completely different.. If you don't then it will look like you're replying to the old thread (assuming your mail reader actually groks threading) and that can be most confusing.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 64 bit vs 32 bit
On Tue, 7 Aug 2007, Chris Stankevitz wrote: > Daniel O'Connor wrote: > > (ie I am wondering if anyone has done a comparison) > > My Gnuradio block which does processing in 64 bit doubles runs nearly > twice as fast under 64 bit ubuntu over 32 bit ubuntu. Hardly a good > comparison though since your blocks probably don't do the same thing. Probably not, but interesting nontheless! :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 64 bit vs 32 bit
On Mon, 6 Aug 2007, Eric Blossom wrote: > > It would probably be a fairly marginal difference though.. > > (Right? I haven't done any tests..) > > Twice as many registers available for the compiler in 64-bit mode. > This makes a big difference, since the X86 architecture is register > starved. Yes, I am aware there are architectural improvements but theory doesn't always hold :) (ie I am wondering if anyone has done a comparison) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 64 bit vs 32 bit
On Mon, 6 Aug 2007, Manaen Schlabach wrote: > I was afraid of that. It looks like I will be reinstalling my distro > :) It would probably be a fairly marginal difference though.. (Right? I haven't done any tests..) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Website down?
On Friday 22 June 2007 22:14, Trond Danielsen wrote: > 2007/6/22, Teun van Berkel <[EMAIL PROTECTED]>: > > gnuradio.org down? :( > > It works just fine in my little corner of the world. It was broken for me earlier today (couldn't resolve the name) but now it works fine. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpIYdro1OoPT.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] compile problem (libusb on FreeBSD)
On Thursday 21 June 2007 12:06, Adam Skelton wrote: > I'm trying to build gnu radio on FreeBSD. It will go through the > basic configure but dies when I force it to build usrp, because > it says it can't find the library containing usb_bulk_write. But > I have libusb in /usr/local/lib and strings says it has > usb_bulk_write, and the function prototype is in /usr/local/ > include/usb.h. All help is appreciated. How do I check to see > which library file it is reading, or how it goes about > determining this. I glanced at the configure script but it's a > little over my head. You didn't say what you tried, however I would suggest running configure like so will work.. env CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure ... This tells configure to look in the right place for include files and libraries when doing its tests (and passes that info on to the Makefile) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpLR42hEizTY.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using gpu's for accelerating computations
On Friday 15 June 2007 04:52, Rohit Garg wrote: > Has any body tried porting the compute intensive portions to GPU's. > The task apparantly is ideal for GPU's to digest. I know that GPGPU > is, as yet, more research and less apps area, but I feel that it will > be valuable addition. http://www.google.com/search?q=gnuradio+gpu&ie=UTF-8&oe=UTF-8 :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpGP4FbzWog1.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mobile Power Supply for USRP
On Thursday 10 May 2007 08:56, Charles Swiger wrote: > 9.6 to 14V in, 5.5V at 5A out. I was worried about the ripple in the > output (see data sheets) but has not been a problem. I think that even if there is the input filtering and regulator should cope with it. Or if not it should be re-designed ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgplBzI60p02j.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mobile Power Supply for USRP
On Monday 07 May 2007 10:09, Daniel O'Connor wrote: > They also sell DC/DC converters that will go down to 3.3V but then > you would need to remove the existing regulator and it would almost > certainly be much noisier without the linear regulator in there. Or you could try finding something like this.. http://www.morex.com.tw/products/productdetail.php?fd_id=62 A retailer .au gets them, and I think you'd be able to find someone who imports it in the US easily enough. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp7jKyhD4lFV.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mobile Power Supply for USRP
On Monday 07 May 2007 11:24, Matt Ettus wrote: > Most of the daughterboards regulate the 6V down to 5V, so you really > need about 5.5 to 5.75 V to operate correctly. Ah right, I didn't realise they powered off the "before" section of the regulator. Going straight to 3.3V would be suboptimal for noise anyway and probably not save you that much. > Matt > > Daniel O'Connor wrote: > > On Monday 07 May 2007 00:29, Eric A. Cottrell wrote: > >> Is there a off-the-shelf product to power the USRP from 13.8 > >> volts? My understanding is the USRP needs a couple of amperes at 6 > >> volts. The best I saw was 1 Ampere maximum output. > > > > I think you could use DC-DC converter that outputs 5V. > > > > The dropout on the regulator used is 1.5V, and 3.3 + 1.5 = 4.8V. > > Not a lot of headroom but it should work OK.. Right? :) > > > > You could test it using your PC power supply before spending money > > too. > > > > Farnell sell DC/DC converters that will do the job but they are not > > cheap (>AU$100) > > http://au.farnell.com/jsp/Electrical/Power+Supplies+&+Converters/PO > >WERBOX/PBBA-1205F/displayProduct.jsp?sku=3821067 > > > > They also sell DC/DC converters that will go down to 3.3V but then > > you would need to remove the existing regulator and it would almost > > certainly be much noisier without the linear regulator in there. > > > > > > > > ------- > >- > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp1GNXQNrxmO.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mobile Power Supply for USRP
On Monday 07 May 2007 00:29, Eric A. Cottrell wrote: > Is there a off-the-shelf product to power the USRP from 13.8 volts? > My understanding is the USRP needs a couple of amperes at 6 volts. > The best I saw was 1 Ampere maximum output. I think you could use DC-DC converter that outputs 5V. The dropout on the regulator used is 1.5V, and 3.3 + 1.5 = 4.8V. Not a lot of headroom but it should work OK.. Right? :) You could test it using your PC power supply before spending money too. Farnell sell DC/DC converters that will do the job but they are not cheap (>AU$100) http://au.farnell.com/jsp/Electrical/Power+Supplies+&+Converters/POWERBOX/PBBA-1205F/displayProduct.jsp?sku=3821067 They also sell DC/DC converters that will go down to 3.3V but then you would need to remove the existing regulator and it would almost certainly be much noisier without the linear regulator in there. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp3TbVgOlroM.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: PCIe know-how?
On Monday 05 March 2007 11:26, Brian Padalino wrote: > I don't think you need anything PCI with the specified PLX chip. > > The PEX8311 has a description of: > > "8/16/32-bit, 66MHz, Local Bus to PCI Express Bridge" Whoops you are right. Weird I haven't seen that before on their site, maybe I'm going blind :) > > As far as I am aware there are no PCIe equivalents to the PLX 9054 (for > > example) - ie PCIe to local bus bridges. > > I believe that is an equivalent, but still relatively expensive in > comparison to just a PHY chip. Yeah, but your average hobbyist can't afford $100k for a PCIe core ;) > > You might need some information about laying out your board for PCIe > > compliance however you can probably glean that information from a PLX > > example design :) > > Very true - they seem to have the board layout all right there from > their reference design development board. Pretty nice! Handy indeed :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpBrAm61OHpq.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: PCIe know-how?
On Monday 05 March 2007 07:44, Brian Padalino wrote: > With regards to the PCIe interface, were you looking more at just > getting a PHY transceiver and putting the MAC and other layers in the > FPGA, or were you more interested in having a PCIe bridge chip that > handles all of that for you? > > I know Philips and TI have PCIe transceivers which work with Xilinx > and Altera IP for the MAC layer, but what I really found interesting > was a PCIe bridge chip from PLX technologies. It's a relatively hefty > BGA, but if you can place it properly the chip could really be a huge > help. No NDA's are required and the information can be found here. You would still need a PCI core although you can get those a lot cheaper than PCIe cores. You can even get a free one from OpenCores (there is a PCI to wishbone bridge for example). As far as I am aware there are no PCIe equivalents to the PLX 9054 (for example) - ie PCIe to local bus bridges. You might need some information about laying out your board for PCIe compliance however you can probably glean that information from a PLX example design :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpmNy0goeVjx.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VHDL help!
On Monday 05 February 2007 20:20, Davide Anastasia wrote: > I'm trying to realize a 1 bit quantizer on the FPGA, but I've some > problem to understand how VHDL works! > > So, I hope you can help me. > In the file /usrp/fpga/sdr_lib/rx_buffer.v there are two wire: > >wire [4:0] bitwidth; >wire [3:0] bitshift; > > What's the function of these? This is Verilog not VHDL.. They declare wire buses you can use to connect things together with. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpvS9WxVCC2C.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PlayStation 3
On Friday 19 January 2007 08:58, Eric Blossom wrote: > On Thu, Jan 18, 2007 at 01:27:51PM -0800, Kyle Kuypers wrote: > > I think Gentoo will provide us with a very capable cross dev environment. > > I've installed Gentoo on a PS3 and used its built-in distributed compile > > and crossdev features to offload most compiling of the normal linux > > binaries for the PS3 onto my workhorse machines. > > OK. I'm assuming that these aren't specific to Gentoo. > At a minimum, I'd like a generic Linux solution. I imagine distcc will do the job (although you need the right gcc installed on the work machines) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpmBnFPtYc95.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gmsk in light of fpga modifications
On Friday 19 January 2007 01:19, Brett L. Trotter wrote: > > Also you might be running out of entropy.. > > Saw the entropy problem when using /dev/random, but /dev/urandom seems > happier- in either case, at some point, ctrl+c's quit working and the > session basically locks up (with scp, it eventually stalls out- the most > I transferred was a MiB)- but typing causes packets to traverse the > tunnel even though the typed text does not render, nor seem to reach the > other end. I ran a ping -A and lost '0%': Hmm, at least in FreeBSD urandom will give you randomness even when the entropy pool is empty, whereas random will not. I believe that reading from urandom will consume entropy if it is available - this could cause a problem if SSH later needs randomness as it will block reading from urandom. > So bottom line is, the ssh dies off. I'm going to try out the tcpdump > suggestion from Greg Troxel and see what things look like. Good idea :) > It's possible that the interface is seeing so many errors that the > checksums occasionally work out despite the errors- I'm going to also try > increasing the symbols/sample. Hmm, but TCP will correct for these errors - it only uses 32 bit CRC but it's not that likely to give a false positive. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpNB4nrRnYEn.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gmsk in light of fpga modifications
On Thursday 18 January 2007 21:31, Brett Trotter wrote: > I realize ssh probably isn't the best thing to test with, but it happens to > be a quick and easy way to test file sending. The question is, is our > tunnel acknowledging corrupted packets instead of asking for resends? The > question I'm asking ultimately is, what would cause corruption of the ssh > session? I suggest you install something like netcat (ftp://coast.cs.purdue.edu/pub/tools/unix/netutils/netcat/) and see if raw socket connections help things. Also you might be running out of entropy.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgplCaLVmfFAJ.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error: X is required...
On Tuesday 19 December 2006 07:00, Cicale Randy S 2dLt AFRL/VSBXI wrote: > I'm trying to install the GNU Radio on a Debian system and found that I > need Xrender to install Xft to install Pango to install GTK+ so that I can > use the wxgui module. > > X windows is located in the typical directories: /usr/X11R6/bin/ and > /etc/X11/ I've used ./configure --prefix=/usr/X11R6/ as well as no prefix > specified. I always get the error: > > Checking for X... no > Configure: error: X is required, but it was either disabled or not found. > > Any ideas on how to get this to work? I know X exists because I can use x > windows. If that fails- how about help on just using text based gnuradio > programs? 1- Try reading config.log in the build directory. 2- Try env CPPFLAGS=-I/usr/X11R6/include LDFLAGS=-L/usr/X11R6/lib ./configure -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpeje3Ml2cXc.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] intel announces quad-core processors
On Wednesday 06 December 2006 03:37, Eric Blossom wrote: > http://www.intel.com/technology/magazine/computing/quad-core-1206.htm Pitty they're AU$1700 each or so ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpYpcOYOkwjP.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple C files required by single C++ block.How to build?
On Thursday 30 November 2006 06:35, Jonas Hodel wrote:
> Then:
> Within “howto_square2_ff.h” I added #include “test.h”.
> Within “howto_square2_ff.cc” I added a call to jonas_test(), located in
> the constructor howto_square2_ff ().
> I added test.c to the “_howto_la_SOURCES” entry in “src/lib/Makefile.am”.
>
> Finally: “make clean”, “make” and “make check”.
>
> This results in:
>
> ImportError:
> /home/jonas/gnuradio/gr-howto-write-a-block-3.0.2/src/lib/.libs/_howto.so:
> undefined symbol: _Z10jonas_testv
I think this means that the compiler has generated a reference to a C++
symbol - note the mangling in front.
I think you need to tell the compiler it's dealing with C when you declare the
prototype for your C function.
I believe you do..
extern "C" {
#include "HeaderForMyCFunctions.h"
}
but my C++ fu is weak.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
pgpbeG6vIHuse.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple C files required by single C++ block. How to build?
On Wednesday 29 November 2006 09:26, Jonas Hodel wrote: > I have some existing C-functions which I would like to include in a C+ > signal processing block. The complication is that these C-functions are > located in a number of different files. I have created a C++ block which > uses these functions. It appears to build fine but when I come to > include the new block in my python script I get an “undefined symbol” > error referring to one of the low level C-functions (I think). In short, > is it possible to use my existing C-files unchanged (included in my C++ > block)? If so what approach is necessary to make this work/build properly? You need to compile those .c files into .o files and then link all your .o files together then it should work fine. I don't know how to get the GNURadio build system to do that for you though (probably just appending the names of the .c files to the list of source files will do it though) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgplm90TfqkYk.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PS3/Cell BE platform
On Friday 17 November 2006 09:42, Jason wrote: > instructions/functions. It involves, from preliminary review, wrapping > the chunk of code you want on the SPE in an spu_thread, shipping data in > and out via DMA, minimizing ooo (out of order, ie branchy) code, then > reworking the algorithm to take advantage of the SIMD (single > instruction, multiple data) instruction set. Once that's done, > recompile it with IBM's modified GNU toolchain, and watch it crash. :) I wouldn't be surprised if a patch for fftw turns up pretty quickly.. I imagine the code in there is already fairly branch free and organised for SIMD operation because of the existing MMX/SSE optimisations. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp5VlODzP4Mk.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PS3/Cell BE platform
On Thursday 16 November 2006 16:22, Robert McGwier wrote: > The Nividia GPU's have fft and blas running on them. They are doing > teraflops and the tools/SDK are available under NDA. They do indeed > have multiply , accumulate, etc. ATI/AMD have something similar.. http://ati.amd.com/companyinfo/researcher/resources.html (Not that I have used either) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpr62deDxpzD.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large RX Delay
On Tuesday 14 November 2006 12:10, Thomas Schmid wrote: > I use the outb command to change the parallel port. From what I read, > that command should have a delay of around 1 \mu s, not more. I am not Hmm, well you probably will incur a few microseconds because you need to talk to the legacy hardware which tends to be very slow. You won't have any context switch or syscall overhead though. > sure about the context switches, but I am almost sure that this is not > the problem. I don't run anything else on the machine (i.e., no other > heavy load process), and the machine is pretty powerfull (dual CPU, > dual core with huyper threading, that makes 8 CPU's under linux). If > it helps, I am running the stock Ubuntu 6.10 kernel (2.6.17-10-generic > #2 SMP Fri Oct 13 18:45:35 UTC 2006 i686 GNU/Linux). Additionally, I > was able to measure the TX delay for burst transmission with a similar > technique to be in the order of a couple of hundred \mu s. This is why > I am wondering about the large RX delay. Not sure hyperthreading is a good idea here. The virtual cores may be stalled without you really knowing. I wouldn't imagine it would have such a large effect as you are seeing though. Not really sure what else to try though sorry.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpzvjKy7KkKm.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large RX Delay
On Tuesday 14 November 2006 11:33, Thomas Schmid wrote: > First of all, I don't understand why we have such a high delay. > Shouldn't it be more in the hundreds of /mu s instead of in the ms > range? Second, why is the delay shorter for decimation 64, and again > larger for a decimation of 256? How many times a second is your OS switching process context? How are you frobbing the parallel port? Does it involve a syscall? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpXZpF6YvDX3.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Timers
On Thursday 02 November 2006 01:55, Eric Blossom wrote: > We don't explicitly use setitimer, but there's a chance that Python > could be using it behind the scenes for reasons of it's own. Would it be possible to spawn another thread and use usleep or select to wait for the desired length of time? (This is addressed to the OP but I deleted that message) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpcMChcAjkOv.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb and select(2)
On Sunday 15 October 2006 11:53, [EMAIL PROTECTED] wrote: > [*] Not counting threads. Quoting Alan Cox: "Computers are state > machines. Threads are for people who can't program state machines." USB's IO model is not well suited to select() style applications since it doesn't allow it to tell the OS how much data should be read in advance (since there is no real way for a USB device to flag it has data to be sent to the app). Async. IO is a much closer match but support for that in your OS may be limited. (Especially for raw device nodes and USB in particular) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpF8AhYXLJte.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with make
On Friday 06 October 2006 06:46, De Lima Julian wrote: > I have gcc3.4 and g++3.4 and when I do the ./configure there is no problem. > But after when I do the make, I have this mistake : > > ../../../../gnuradio-core/src/lib/general/gri_agc2_cc.h:40: warning: when > initialized here gnuradio_swig_python.cc: In function `PyObject* > _wrap_gr_multiply_vss_sptr_set_detail(PyObject*, PyObject*)': > gnuradio_swig_python.cc:254: internal compiler error: in init_alias_analysis, > at alias.c:2962 > Please submit a full bug report, with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > For Debian GNU/Linux specific bug reporting instructions, > see . ... > What is the problem ? I have installed all the packages I think. > Thanks You got an internal compiler error, nothing to do with make. I would suggest your hardware is probably broken, probably RAM, but possibly your motherboard, CPU or power supply. Download Memtest86+, burn it onto a CD and run it for a few hours. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp0l19z9fCf6.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Active Radar Hardware
On Saturday 30 September 2006 00:04, John Ackermann N8UR wrote: > But also realize that in addition to preventing physical damage to the > receiver, you also need to deal with "desense" (as we old repeater > builders call it) that results when the RX front end is subjected to a > strong input. It takes a finite amount of time for the front end > operating conditions to return to normal after being exposed to a big > signal, so that may impact your turn-around time. If the Rx boards support it you could turn off the LO during transmition, that can improve recovery time. (Although this is all second hand knowledge at VHF :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpJmARTCnCxf.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] to prevent mental damages, avoid dB's.
On Friday 29 September 2006 20:55, David Bengtson wrote: > > Might be worth writing a Python version for GNU Radio - it would be > > pretty simple I think. > > How about going old school and using a calculator? No memory footprint > on the computer at all. Yeah, funny thing about computers, they were invented as labour saving devices :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpRs7dihIKKT.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] to prevent mental damages, avoid dB's.
On Friday 29 September 2006 12:33, Brian Padalino wrote: > I am really surprised on how you guys are so anti-spreadsheets. > > A lot of the RF engineers where I work like using them when designing > their receive and transmit chains for calculating tolerances and all > sorts of noise figures. > > One even modeled the front end amplifier gain stages for which DAC > values should be used at each input power over our 75 dB of gain so > when I wrote the FPGA module to actually do the AGC we could compare > my simulation results with their ideal gain for any given input. This sort of thing makes perfect sense for a spreadsheet. Our RF engineer uses them for working out receiver gain distribution and other things. We use the Tcl/Tk program for doing stuff like calculating output power of a transmitter as you look at the scope on its sniff port.. much faster than loading a spreadsheet :) Languages like Tcl are *very* easy to program even for novice coders (like our RF engineer :) and are usually very portable as well. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpCw4TYz1pjk.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] to prevent mental damages, avoid dB's.
On Friday 29 September 2006 11:49, Berndt Josef Wulf wrote: > BTW: I do these calculations in my head - pretty much primary school stuff > really. Yeah, depends what level of accuracy you need though :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpx9KYUHV40M.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] to prevent mental damages, avoid dB's.
On Friday 29 September 2006 11:33, Brian Padalino wrote: > You could open Google Spreadsheets in the web browser you've probably > already got open. Not only that, but you can share it with your > buddies for collaborative editing so everyone can use it! Or write it in javascript.. > Or you could just write a bc script to to handle it. That uses much > less memory, I am sure. Lacks flexibility. > Or we could ask Google to build it into their calculator function so > you can just type "200 dB in mW" and it would do the conversion for > you! Kind of slow. > I wasn't trying to be a jerk, but I have noticed that spreadsheets are > much better at converting data to a visual format as well as extending > a dataset you might be building and doing some visual interpretations. > There's always more than one way to skin a cat, as GNURadio is all > about. Spreadsheets take too long to load, we already have tcl/tk stuff running because our radar uses it. Presumably a Python version would be good for GNURadio since you'd already be using it :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpBPo9e8s1F3.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] to prevent mental damages, avoid dB's.
On Friday 29 September 2006 10:13, Brian Padalino wrote: > A spreadsheet could work just the same without all the Tcl/Tk > silliness or input verification problems. Yeah, a spreadsheet, so lightweight compared to a memory hungry Tcl/Tk application. 12623 radar 1 1030 11972K 6068K select 0:00 3.97% wish8.4 12643 darius6 200 120M 72048K kserel 0:07 0.00% soffice.bin *cough* Not sure what you mean about input verification. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpbf93Fm4plu.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Active Radar Hardware
On Friday 29 September 2006 07:30, Jason Hecker wrote: > > lot more about it, and looking for better parts, but I've learned to ask > > the experts early ;) Any ideas? > > I used to write software for a radar. It used separate antennas for I still do :) > transmit and receive for several reasons though the RX and TX antennas were > located right next to each other. This arrangement works very well. If > you are concerned about too much power entering the RX stage you could use > a switchable attenuator using a voltage signal and PIN diode. Actually, if We make MF & VHF systems and for some of our VHF systems we use a single set of antennas and a T/R switch (passive and active). However since our frequency of operation is 2-3 orders of magnitude lower it's probably all different... > you want any sensible readings and a signal that has good dynamic range at > the ADC you will need a controllable attenuator that increases the RX gain > over time (in a logarithmic way) as the return signal gets weaker with the > squared square of the distance (R^4 !). You'll always get overload signal > for a certain close-in range anyway. Not much you can do about that. For boundary layer/troposphere radars we halve our effective PRF and transmit a short low power pulse and listen with a low gain setting on even pulses and a high power long pulse with high gain on odd pulses. The sampling configuration also alternates to sample low and high. I guess the other possibility is being adaptive, ie adjust your power/gain based on what you can currently see. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpDeF8B7uZH9.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] to prevent mental damages, avoid dB's.
On Friday 29 September 2006 09:21, John Ackermann N8UR wrote: > I have to say that I like dBs, too. All you have to do is remember two > things: 3dB doubles the power, and 10dB is 10 times the power, and from > that you can SWAG just about anything. A guy at work wrote a handy program in Tcl/Tk for converting power between various units (dBm, mW, Volts & Pk-Pk Volts). Might be worth writing a Python version for GNU Radio - it would be pretty simple I think. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpttPpYS8Apq.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The coming deluge of CPU cycles
On Friday 28 July 2006 15:29, Eric Blossom wrote: > > So if you wanted to use it you'd have to set up some local memory and > > then copy data into that (from the FPGA) and then signal the host when a > > "page" is done so it can program the PLX chip. Means you get an interrupt > > every page which seems inefficient to me. > > That's why you want to use one one of the bus mastering PLX parts. > No host intervention in the tranfers after setting them up. You can > build a big S/G DMA chain, and only get an interrupt at the end, or > every N pages, or whatever. Yes, but you can't use the built in S/G engine because it's.. limited. The only way to enable/disable it is to program the DMA registers. If the S/G engine is doing writes to PCI it wants to be the local bus master - that's OK except that it may get an abort and will want to re-read some data so you have difficulty knowing for sure if it has truly finished with the data and you can throw it away. To my mind that means you either copy the data into RAM on the card and tell the PC how many pages are available and it sets up the PLX chip, or you use the bus mastering capability and make your own SG engine. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpZorQ8T2wor.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The coming deluge of CPU cycles
On Friday 28 July 2006 01:39, Eric Blossom wrote: > > method as well. No need to implement 802.3af (I think that's the > > spec.). Even though there are no spare pairs to use for a DC feed on a > > GigE CAT5 cable there are ethernet transformers which can isolate and > > insert a common mode DC current onto a pair of CAT5 wires. > > I think it would be hard to get enough power for the PA over the CAT5. From what I can see you can draw up to 13W.. That said running a power cable to your antenna is not terribly onerous IMO. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpj47Y4gAGqh.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The coming deluge of CPU cycles
On Friday 28 July 2006 01:33, Eric Blossom wrote: > > A 9030 is target only, you'd need a 9054, 9056, 9060 or 9080 otherwise > > the performance would not be very great. > > Good point. I've written drivers using the 9080 before it was pretty > easy to use. The scatter/gather stuff worked fine for me, at least > from the point of view of the host side. Yeah, I mean to say that you COULD use it, but it would need more host intervention and/or a reasonable amount of on card buffering. You can't (as far as I can see) say to the SG engine that it's reading from a FIFO and it should treat the data as precious. Also there is no input to the PLX chip to allow you to gate reads (ie a data available pin). So if you wanted to use it you'd have to set up some local memory and then copy data into that (from the FPGA) and then signal the host when a "page" is done so it can program the PLX chip. Means you get an interrupt every page which seems inefficient to me. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpRESBVnqAmT.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The coming deluge of CPU cycles
On Thursday 27 July 2006 16:09, Jason Hecker wrote: > > That's one route, though 32-bit 33-MHz PCI is pretty much the bottom > > of the barrel these days. Hence the interest in PCI-Express and/or > > Express Card. > > True. At a glance I couldn't see any alternative from PLX for faster > PCI busses. PLX's chips are fairly inexpensive though. As an > alternative could you use an FPGA as the PCI-Express to USRP MkII > interface? PLX don't have any "IO Accelerators" for PCI express. They do make a PCI express to PCI converter though ;) I dunno how much PCI-e soft cores cost, but it looks like one of the "easier" routes to doing PCI-e :( You need an interface chip (BGA..) unless you're using a Virtex-4 though (dunno what that translates to in Altera-land) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpfeM5JyoJMf.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The coming deluge of CPU cycles
On Thursday 27 July 2006 15:39, Jason Hecker wrote: > Would an extra bit of hardware such as a PCI card with PLX's PCI9030 > breaking out to the USRP with something like an 80 wire IDE cable be > suitable for high bandwidth, low latency and lowish cost? > > (http://www.plxtech.com/products/io_accelerators/PCI9030/default.htm) A 9030 is target only, you'd need a 9054, 9056, 9060 or 9080 otherwise the performance would not be very great. Another option is to use a PCI soft core but then you run into licensing issues. I have looked at these for work and one problem (for us anyway) is that the S/G engine doesn't treat the data as precious so it's not very useful for reading from a FIFO. It's quite frustrating because that means you have a chip which has an S/G engine built in but you have to make your own anyway :( I'd love to be shown to be wrong though ;) > I know someone who used gigabit ethernet driver chips hooked to an FPGA > in order to push lots of digitised SVGA video data down a long length > of CAT5e for a KVM application. Was that really ethernet framing? Or just using the CAT5 cable as 4 differential pairs? (Not that there's anything wrong with that - I imagine you'd still get good cable lengths with the right drivers) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpJojBfy6YU2.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The coming deluge of CPU cycles
On Thursday 27 July 2006 02:23, Marcus Leech wrote: > So, I read yesterday that Intel is going to start introducing quad-core > CPUs sometime late this > year, rather than 2007 as originally announced. Let's hope they fix their bus architecture first otherwise they'll all be starved for memory bandwidth :) You can get dual or quad CPU boards and put dual core CPUs in them already.. I would suggest that would be more useful since (for AMD64 anyway) each socket has some local RAM which would mean less contention. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp6prx62LPen.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB2, 32 MByte/s or 480MBit/s?
On Friday 16 June 2006 13:19, Thomas Schmid wrote: > I was wondering why can the USRP "only" achieve 32 MByte/s, i.e. 256 > Mbit/s whereas the USB 2.0 specifications are 480 MBit/s? The 32 > Mbyte/s is mentioned in several earlier posts on the gnuradio mailing > list archive and in the BBN report (freebsd section). For starters USB only does 480MBit/sec on the physical layer. It has quite a number of overheads which prevent this throughput being fully realised. I believe the practical throughput IS higher that 256MBit/sec but I don't know for sure (or what the bottleneck is) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpoGWWixnrAI.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Car alarms and garage door openers
On Tuesday 06 June 2006 05:59, Matt Ettus wrote: > After the Wired article today, I've received a couple of email from > people who are concerned that the USRP could be used to clone their > keyfob transmitters for car alarms and garage doors. I'm not concerned, > since there are already many ways to do this (just check the back of > pupular science magazine). However, I am curious about it. I know that > we can capture and play back any rf signal. The question is whether > that replayed signal would result in the door being unlocked. I was > under the impression that most of those systems allow an unlock code to > only be used once, but does anyone out there know for sure? "It depends" Some car systems are pretty sophisticated and cycle through codes to prevent replay attacks. AFAIK most garage door openers are pretty simple, although I guess it would be fairly easy to check by listening to one and seeing what, if anything, changes from press to press. Microchip make a tx/rx pair that has funky crypto (although I haven't looked at how good it really is). Don't forget dorbells! I have a 433MHz wireless doorbell which could be cloned 8-) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpvvYz1QY64i.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 48KHz audio board
On Sunday 14 May 2006 07:19, Vincenzo Pellegrini wrote: > my audio board requires 48Ksps > the fm receiver in gnu radio examples delivers to it 32Ksps instead. > setting a overall decimation factor of 1320 i can get as near as 48484 > samples/sec. > > but even if much better, this still gives problems. and there's no > integer factor that can take 64Msps to exactly 48Ksps. > > can anyone help a newbie? I think you need a resampling function (or a smarter sound card ;) eg sox can resample from one frequency to another, I don't know if there is such a block in GNURadio though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp1wabY9ONZp.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] nanosecond timing under Linux
On Friday 12 May 2006 08:28, Lee Patton wrote: > Any suggestions for getting nanosecond (or at least, sub-microsecond) > timing under Linux? The best I've Googled have been platform-dependent > assembly timers. I know FreeBSD has [get]nanotime() but I don't know how portable that is (probably not at all). Also, if you are using this to tag USRP streams you are probably better off finding some way to sync the start of acquisition to something and then counting samples. That way it's "free". (at work our acquisition system syncs to GPS 1PPS and if we need mucho accuracy we use GPS disciplined Rubidium clocks driving a PLL) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgplNtkukek09.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Auto* again
On Wednesday 10 May 2006 12:49, LRK wrote: > The 'libtool' problem under FreeBSD has always been related to some problem > with FreeBSD not setting pointers to specific versions of the tools. This > particular one is usually due to aclocal looking for libtool.m4 in the > wrong place. Seems like there was a change recently. > > This is my note on the FreeBSD 5.4 machine but I think the 'libtool15.m4' > is now just 'libtool.m4'. > > ln -s /usr/local/share/aclocal/libtool15.m4 \ > /usr/local/share/aclocal19/libtool.m4 Ahah, thanks! I note there was a big auto* change recently, but quite frankly, I try and avoid reading about it so my head doesn't explode :( Maybe you should a send-pr about that as it may get incorporated into the auto* ports as a fix. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpuEGnvreELx.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Auto* again
for python extension module directory...
${exec_prefix}/lib/python2.4/site-packages
checking for Python include path... /usr/local/include/python2.4
checking Python.h usability... yes
checking Python.h presence... yes
checking for Python.h... yes
checking for swig... /usr/local/bin/swig
checking for SWIG version... 1.3.29
checking for socket in -lsocket... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... -D_THREAD_SAFE
checking for cc_r... gcc
checking for library containing clock_gettime... none required
checking for clock_gettime... yes
checking for gettimeofday... yes
checking for nanosleep... yes
checking sys/ipc.h usability... yes
checking sys/ipc.h presence... yes
checking for sys/ipc.h... yes
checking sys/shm.h usability... yes
checking sys/shm.h presence... yes
checking for sys/shm.h... yes
checking for library containing shmat... none required
checking for ANSI C header files... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for strings.h... (cached) yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking linux/ppdev.h usability... no
checking linux/ppdev.h presence... no
checking for linux/ppdev.h... no
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking for sys/types.h... (cached) yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking for stdint.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for working alloca.h... no
checking for alloca... yes
checking for function prototypes... yes
checking whether setvbuf arguments are reversed... no
checking for vprintf... yes
checking for _doprnt... no
checking for mmap... yes
checking for select... yes
checking for socket... yes
checking for strcspn... yes
checking for strerror... yes
checking for strspn... yes
checking for getpagesize... yes
checking for sysconf... yes
checking for snprintf... yes
checking for gettimeofday... (cached) yes
checking for nanosleep... (cached) yes
checking for sincos in -lm... no
checking for sincosf in -lm... no
checking for sinf in -lm... yes
checking for cosf in -lm... yes
checking for trunc in -lm... yes
checking for library containing shm_open... none required
checking for shm_open... yes
./configure: line 9761: AC_PROG_LD: command not found
checking whether accepts --enable-runtime-pseudo-reloc... no
checking for CreateFileMapping function... no
checking for sys/types.h... (cached) yes
checking for fcntl.h... (cached) yes
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking for winioctl.h... no
checking for winbase.h... no
checking for getopt... yes
checking for usleep... yes
checking for gettimeofday... (cached) yes
checking for nanosleep... (cached) yes
checking for rand... yes
checking for srand... yes
checking for random... yes
checking for srandom... yes
checking for sleep... yes
checking for sigaction... yes
checking for struct timezone... yes
checking for struct timespec... yes
checking for ssize_t... yes
checking for getopt... (cached) yes
checking for usleep... (cached) yes
checking for gettimeofday... (cached) yes
checking for Sleep... no
checking whether mkdir accepts only one arg... no
checking for dot... YES
checking for pkg-config... /usr/local/bin/pkg-config
checking for fftw3 >= 3.0... yes
checking FFTW3F_CFLAGS... -I/usr/local/include
checking FFTW3F_LIBS... -L/usr/local/lib -lfftw3 -lm
checking FFTW3F_INCLUDEDIR... /usr/local/include
checking for machine dependent speedups... x86
checking for cppunit-config... /usr/local/bin/cppunit-config
checking for Cppunit - version >= 1.9.14... 1.10.2
gr_boost_include_dir = /usr/local/include
checking boost/shared_ptr.hpp usability... y
Re: [Discuss-gnuradio] USRP transfer sizes
On Monday 08 May 2006 04:54, Matt Ettus wrote: > Some notes on the data pipeline and buffering: [snip] Seems like a hint to tell ugen what size block to read ahead with should work very well. I wonder what bugs you'll find in the EHCI code though ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpXDYqltfCMh.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD
On Monday 08 May 2006 01:18, LRK wrote: > > A kernel driver could issue the multiple reads but it is a fair amount of > > work to write one, and a bit of a waste if ugen could be extended instead > > (hence benefiting other applications) > > Obviously it would be neat to extend ugen if the fixes were generic but if > there need to be USRP-specific fixes they would best be done in a different > module. Maybe I'm not understanding this but it looks to me like ugen just That's where you are wrong. Writing a new module means writing (or copying) new code. If you copy ugen that means that any fixes for it need to get duplicated. Also, since the USRP isn't a "main stream" device it is likely OS changes will break it unless the maintainer is very active. If you write a driver from scratch (which would be pretty silly given that ugen is almost exactly what you need) then you will take longer and have to fix more bugs. > It also seems that the USRP tx and rx paths normally use the same block > size after each open. If that is right, the driver could simply use that > block size until the stream is closed, reading ahead on rx and providing > flow control on tx. Yes, but I think extended ugen to allow the user program to supply a hint to say "here is the block size, and keep reads queued" (via ioctl for exampe) is probably a lot simpler than creating a new driver. > It appears the attempts to read the USRP at more than 4 MB/s just lock > and transfer no data. Changing the 'read' in libusb to just return as > though it had finished results in the 'test_usrp_standard_rx' giving > similar results at all speeds including the pattern of overrun errors. > The transfer rate calculated is very fast so the overrun error count > seems to be a function of the USRP code rather than actual overruns. The problem is that with no back to back transfer you are wasting slots (USB divides time into slots it will transfer data in). The limit of 4Mbytes/sec is because of the number of slots per second (divided by 2 I guess) multipled by the maximum block size for a bulk transfer. > I guess this is getting much too complicated for the old guys like me > to comprehend so I'll offer encouragement and await a solution, sooner > the better. It's OK, USB is complicated for younger minds too 8-) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpgpCVZgWKmT.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD
On Saturday 06 May 2006 23:35, LRK wrote: > I would like to run GR under FreeBSD so I am looking forward to your > progress on this. > > > Under FreeBSD (and probably NetBSD) the ugen(4) device is generic and gets > assigned to any unknown device. I would suggest you look into getting a > number assigned to the USRP and a name assigned for it, say usrp(4). Any > application more serious than experimental would seem to justify it. Creating a kernel driver won't magically make things go faster, it is also more complicated as you have to write a driver and the code to talk to it.. IMO the best solution would be AIO but that isn't very portable, next best is hacking ugen to not have so many restrictions. This is because of the USB IO model - the problem is that ugen does not know how big a block of data to request from the device, and unlike more traditional devices it does make a difference (since USB allows you to request certain size transfers as well as allow short transfers). The fix for ugen is to supply it with a hint to say what size transfer it should queue up after the current one has been done. This gives you more transfers in flight and greatly improves throughput. There have been attempts to fix ugen in FreeBSD to do this but it didn't work very well because the API was not extended to provide the hint so it was backed out. A kernel driver could issue the multiple reads but it is a fair amount of work to write one, and a bit of a waste if ugen could be extended instead (hence benefiting other applications) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp8Dfta4y8cr.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD
On Saturday 06 May 2006 03:19, Greg Troxel wrote: > > I don't know how widely supported it is - in FreeBSD it's optional (via a > > kernel option or KLD). > > This seems to be a POSIX 1003.2 feature. It doesn't exist in NetBSD. OK, a pity. > This is essentially what the Linux USB driver does, but apparently > without using a standard interface. Right. > It's a reasonable match, but it's far more general than what the USRP > needs. The problem arises because we're trying to use the USRP like a > traditional data input device, where data arrives and is buffered. > The current NetBSD ugen(4) code, and it seems the Linux code without > fusb, overload the read system call to both move data to userspace and > to inititiate a read operation over the USB. aio (like Linux fusb) > allows one to avoid the temporal coupling of this overloading. OK. > I don't see any reason why continuous read mode and aio are mutually > exclusive - one could still do an async read. Indeed, I just wanted to make sure you didn't implement a hack when the real thing would be easier :) (ie if NetBSD did AIO then no kernel mods would be necessary) > I think it comes down to two issues: > > 1) Do we want the user-space program to explicitly schedule all the >hardware reads? I am not sure, but I think the answer is no (for the USRP case especially) > 2) Is continuous read mode easier to implement than AIO? Yes :) [since AIO has hooks deep in the kernel] > I find user-space code managing lots of pending reads to be more > complex than it ought to be when we really want to just say "start > reading and keep going". > > I didn't find a clear explanation of how AIO works with multiple > outstanding reads on the same file descriptor. I'm not sure to be honest, but I believe it's just a queue of reads. > I'm not sure how hard AIO is to implement - the kernel already is > doing things async and the read system call is in tsleep. But it's > harder to do that than continuous read mode. Absolutely, it would also be difficult to ensure standards compliance, etc.. IMO not worth it for this one application. I remember there where plenty of subtle bugs fixed in the FreeBSD implementation and even then it is still an optional API due to potential bugs. > Thanks for pointing out aio, though - I had forgotten about that. I should try using it in FreeBSD and see if it works in practice :) Good luck with your implementation! -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpWJSPBl8oJc.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD
On Thursday 04 May 2006 11:58, Daniel O'Connor wrote: > It would be nice if you could do a readv() and then > poll/kqueue/select/signal to see when an iovec has been filled, however I > suspect that would require severe modification of the kernel internals. Ah now I think about it, this is called "aio_read" :) I don't know how widely supported it is - in FreeBSD it's optional (via a kernel option or KLD). It does allow you to enqueue read requests and then later check if they have been completed. IMO this is the best match for the USB IO model, but my USB fu is fairly weak. (And it's not much use if it isn't widely supported..) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpO49GUlJZD6.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD
On Thursday 04 May 2006 03:30, Greg Troxel wrote: > Joanne has written a proposal to modify NetBSD's ugen(4) to get good > performance for the USRP. We'd like feedback about the technical > approach. (Once we have it working, the changes will be commited to > NetBSD-current.) > > http://acert.ir.bbn.com/downloads/adroit/NetBSD-USB-continuous.pdf I think the ioctl would be the cleanest approach - it would not break any existing software. I wonder if it may be possible to have the ioctl specify a packet size and the kernel will keep reading data of that packet size into the buffer as long as it isn't full. I think that would give you something that looks a lot closer to a normal device (normal being "what the unix IO model expects" :) It would be nice if you could do a readv() and then poll/kqueue/select/signal to see when an iovec has been filled, however I suspect that would require severe modification of the kernel internals. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpO7WP9WzeZ7.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grGPS Preliminary Schematic
On Thursday 06 April 2006 15:11, Marcus Leech wrote: > > Also, I think getting 32.768 MHz from 4Mhz with a PLL would be pretty > > difficult (if not impossible) > > Given that you haven't looked into the PLLs on the FPGA, it's rather too > early > to conclude that you couldn't synthesize 32.768Mhz from the 4Mhz > reference clock that's already on the USRP. > Given reasonable dividers for both reference and VFO, I can't see why > synthesizing > 32.768Mhz would be all that difficult. I can understand why you might > want to > use a dedicated oscillator--you don't have to muck with the FPGA. > But asserting that > it's "difficult (if not impossible)" is hard to support if you haven't > looked into it. According to the datasheet the PLL can only do m/n where m is between 1 and 32 and n is between 1 and 4. Therefore I don't see how it's possible. I was only guessing before, but I just checked the datasheet and it seems impossible. You could get close with a Stratix II.. 4 * 498/62 = 32.129 MHz Whereas a Cyclone can only do m/n where m is 1 to 32 and n is 1 to 4. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgptKhoWZUbJw.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grGPS Preliminary Schematic
On Thursday 06 April 2006 13:14, Martin Dvh wrote: > Why don't you use the usrp to generate your 16.384 or 32.768 MHz refclock. > Most daugterboards (except the tvrx) use this feature (They all use a 4Mhz > refclock on io pin 0. The only difference with your design is that you need > another frequency. The cyclone fpga in the usrp has internal PLLs which can > generate all kinds of frequencies. (They are not used at the moment) > > This way you would have a phase coherent system. > Which is very nice if you start to play with multiple gps daughterboards. > > You could then even play with modifying the refclock frequency to receive > other frequencies. (like the russian or the european GPS-like systems, > which are on frequencies near the GPS frequency) Farnell sell 32.768 MHz crystals (They're not what you'd call cheap though - AU$17). Hmm they have 16.384 MHz ones for $12.81. Still not cheap.. Also, I think getting 32.768 MHz from 4Mhz with a PLL would be pretty difficult (if not impossible) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp0fAwNrMwpy.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubunto and GnuRadio, Lovely together
On Monday 06 March 2006 08:14, Robert McGwier wrote: > Yes Matt, I know. I do love to install. Now if Altera would only > release their tools for Linux. They have, but they cost money :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp2BXPut2sNk.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB2.0 card question
On Fri, 6 Jan 2006 10:03, Jonathan Jacky wrote: > I'm using a Belkin F5U222 USB 2.0 card on my 1 GHz PowerBook G4. > This plugs into a notebook computer card slot - it's NOT a PCI card. I suspect it effectively IS a PCI card. Certainly from the OS PoV it would look a lot like one after the Cardbus bridge has configured itself. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpEr2jS3rIUh.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb_darwin / osx code
On Mon, 2 Jan 2006 14:08, Michael Dickens wrote: > Ah ... I was wondering what the linux code did, and that would make > sense; I had thought about that possibility, but didn't want to go > there yet as coding will take a bit of effort (as opposed to the > quick efforts thus far: async w/ feedback, async w/o feedback, sync, > async w/ isoch; all with the same results except for no feedback, > which just didn't work at that really wasn't a surprise). > > As OSX's IOKit provides an async callback with optional user defined > arguments (e.g. used by libusb to get the actual # of Bytes > transmitted), that mechanism can be used to determine when data is > successfully transmitted or received, and then removed from an > appropriate queue. I'll do it in USRP's fusb_darwin (similarly to > the linux code), since it'll be easier to do the list buffering in C+ > +. I will work on that no later than Tuesday, hopefully have a > concept by the end of the week. - MLD Does OSX support aio (async IO)? FreeBSD does, but it's still beta :( Of course I've never used it so I don't know how useful it would really be :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpHzJO51kiut.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gmsk2 - CRC and whitening
On Fri, 2 Dec 2005 09:27, Eric Blossom wrote: > > Processor - Atmel AT90S8535 - face turns beat red. =) > > The AVR processors are very nice. Sort of a minature RISC architecture. > You've got 8K of flash, so I don't see any problem at all. I think > there's a port of GCC that targets it too. There sure is :) http://savannah.nongnu.org/projects/avr-libc http://www.nongnu.org/avr-libc/ The 8535 is pretty crusty though ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpuP1VKf4CYU.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBSRX Noise Figure
On Wed, 30 Nov 2005 16:33, Matt Ettus wrote: > A useful application would be to control a calibrated noise source and > measure the power in a given bandwidth with it on and off. This is how > a noise figure meter works. Noise sources are pretty expensive :( We have one at work though, if someone local is interested in testing it :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpk2G2bp8jmZ.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Linux version of Quartus II kit?
On Fri, 11 Nov 2005 15:16, Martin Dvh wrote: > I tried it under wine. > Didn't succeed (yet). > I think wine has problems with the copy-protection driver/hardware tricks > quartus tries to use. > > If you know how to "patch" software to remove crashing features you might > succeed. Could be worth posting/checking the Wine lists. I'd be suprised if there was any copy protection on the free versions of Quartus, but I could be wrong. > Now I am rebooting all the time between windows and linux. > This is because I also am modifying the fpga design (using quartus II web > for windows) but test gnuradio under linux most of the time. (Because it > compiles faster under linux then under mingw) Probably faster to recompile in Windows than wait for reboots ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Linux version of Quartus II kit?
On Fri, 11 Nov 2005 11:40, David R. Palchak wrote: > Am I right in assuming that a modified FPGA design needs to > be compiled using the Quartus II toolchain? I ask because > as near as I can tell, the only free version of the Quartus > II software requires a windows setup (which I don't have). > Has anyone found an alternative solution? It might work under Wine. I have had reasonable success with the Xilinx tools (in FreeBSD using emulation).. That doesn't help you for this project though :( There is a Linux version of Quartus but it costs US$2000 (!) [Resent unsigned to appease the list software] -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FreeBSD
On Friday 30 September 2005 20:29, Poul-Henning Kamp wrote: > PS: No, I don't have an USRP myself, I keep putting off buying one > until I have time to play with it. Join the club :) I keep trying to get work interested.. Hopefully soon! -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpfSe5fJqr7C.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problems with BSD make
On Sunday 10 July 2005 07:16, Eric Blossom wrote: > Actually, I'm more interested in having a fix for the underlying > problem -- the Makefile.am's that have the non-portable feature -- than > just saying "use gmake". Part of automake's job is have this work > with all makes. I've apparently let some non-portable rule get into > one or more Makefile.am's. Hmm, well while that would be nice in practise 99.9% of FreeBSD boxes have gmake installed :) The main thing is to make sure you call $(MAKE) in your Makefiles instead of make. > I'd appreciate your help in identifying exactly what's screwed up when > building with BSD make. I am fairly sure automake makes extensive use of GNUMake'isms. You can check the BSD make source code out of the FreeBSD repo if you like. (gcc *.c -o pmake compiled it last time I tried :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpj9QmHvgA0i.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Alternative interface from PC to a USRP.
On Sunday 10 July 2005 04:13, Matt Ettus wrote: > Lamar Owen wrote: > >After a brainstorming session at PARI, I've come up with an alternative to > >either USB or GigE, with up to three times the throughput of GigE. > > > >Ultra320 SCSI. > > Interesting idea. How about Serial Attached SCSI (SAS) or Serial ATA? Also, Firewire [800]. > On the other hand, do you really need much more bandwidth than USB2 > gives you? Everyone needs bandwidth :) Of course doing useful work on so much data is usually the problem :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpGQQ41TFnHz.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Xlib problem help request
On Thu, 30 Jun 2005 22:51, Stevie wrote: > > That is really not a very good idea for security reasons.. > > Which is correct. Using > > xhost LOCAL: > > has a similar effect but only opens your X server up to connections > originating on your local machine. Didn't know about the LOCAL: tag - that is most useful. Thanks :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpHyDtHvux7S.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Xlib problem help request
On Thu, 30 Jun 2005 21:15, Stuart Brorson wrote: > > Xlib: connection to ":0.0" refused by server > > Xlib: No protocol specified > > You probably just need to grant all processes access to your X server. > Here's the magic command-line incantation: > > xhost + That is really not a very good idea for security reasons.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpr5iah8mUln.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Xlib problem help request
On Thu, 30 Jun 2005 12:48, EDWARD HALL wrote: > I completed a build with no obvious errors from tarballs, but I get an > error when running applications that I hope someone can help with. I am > using a debian system that began with a Knoppix HD install. The error > messages are as follows: > > [EMAIL PROTECTED]:/home/ward# cd > /usr/share/doc/gnuradio-examples/examples/python/usrp > [EMAIL PROTECTED]:/usr/share/doc/gnuradio-examples/examples/python/usrp# > ./usrp_fft.py -d 8 > Xlib: connection to ":0.0" refused by server > Xlib: No protocol specified This is saying it can't connect to the X server because the X server is rejecting it's auth credentials. I assume you logged into X as a non-root user - in which case try running the usrp examples as yourself, not root. If you need root access I suggest either using sudo, or changing permissions in /dev so you don't need to be root. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpaqUuA39Xy5.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VGA-based DVB-T modulator
On Tue, 14 Jun 2005 09:15, Seth David Schoen wrote: > There's yet another similar project that I would like to track down > that was using a VGA card. > > Does anyone here know if the VGA cards prevent you from controlling > the DAC durinng the blanking intervals? Are the blanking intervals > implemented in hardware or in software? I believe you define certain parameters (including the blanking interval) and the video card only reads data for 'valid' parts although I don't think there is anything that would stop you making a modeline that was very small, or maybe even non existant. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp6WxK3Umcck.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VGA-based DVB-T modulator
On Tue, 14 Jun 2005 08:17, Johnathan Corgan wrote: > I sure wish I could remember where to find it, but I've seen > demonstrated a program that would generate valid AM waveforms by > displaying certain pictures on a video screen. You'd enter a target > frequency (I think in the HF range) and choose a MIDI sound file, and it > would "modulate" the CRT display to emit RFI at that frequency with the > tones riding as AM modulation. Very spooky. It was a demonstration of > the security hazards associated with CRT displays (TEMPEST stuff) in a > very palpable way. There's a link on the page Seth sent.. http://www.erikyyy.de/tempest/ -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpaatl1T6Tto.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Problems building from CVS on FreeBSD
On Fri, 10 Jun 2005 22:38, LRK wrote: > On Fri, Jun 10, 2005 at 03:53:15PM +0930, Daniel O'Connor wrote: > > > ./configure --with-boost-include-dir=/usr/local/include > > gnuradio_core/config/gr_boost.m4 looks for the include directories in > > /usr/local/include/boost-1_31/ which you probably do not have. > > I patch gr_boost to just /usr/local/include Ahh actually I just realised I gave the wrong command line... env LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include SWIG=/usr/local/bin/swig1.3.24 ./configure is what I used. Note that I have an updated SWIG port to get v1.3.24. > The "underquoted definition" means the name does not have the brackets > "[...]" around it which could possibly cause it to be mis-interpreted. > Probably not fatal but you can patch the .m4 files if you want. OK, I'll just ignore them. > > configure.ac:61: warning: AC_PROG_LIBTOOL is m4_require'd but is not > > m4_defun'd configure.ac:61: AC_PROG_LIBTOOL is required by... > > config/gr_scripting.m4:30: GR_SCRIPTING is expanded from... > > configure.ac:61: the top level > > FreeBSD installs libtool15.m4 in /usr/local/share/aclocal but aclocal looks > for libtool.m4 in /usr/local/share/aclocal19. So > > ln -s /usr/local/share/aclocal/libtool15.m4 \ > /usr/local/share/aclocal19/libtool.m4 > > is the easy hack. Ahh Wohoo it compiles :) > or you can copy libtool15.m4 into gnuradio-core/config/libtool.m4 as well > as the other config directories as necessary. I think you can do.. aclocal19 -I config -I /usr/local/share/aclocal to work around this bug. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpp8BVOcoHlL.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Problems building from CVS on FreeBSD
On Fri, 10 Jun 2005 23:41, Daniel O'Connor wrote: > > or you can copy libtool15.m4 into gnuradio-core/config/libtool.m4 as well > > as the other config directories as necessary. > > I think you can do.. > aclocal19 -I config -I /usr/local/share/aclocal > > to work around this bug. No you can't, nevermind :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpOq4mVA42FV.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Problems building from CVS on FreeBSD
On Fri, 10 Jun 2005 22:47, LRK wrote: > Hope by "current" you mean FreeBSD 5.3+ Yep, I am running CVS HEAD of FreeBSD, ie "6.0 prerelease". > Also for unknown reasons, FreeBSD does not install the pointers to the > "latest" autotools. I haven't figured out why so I just put soft links > in /home/gr/bin for those. I think it's a general thing - that is done for other stuff, eg tclsh. In general if you have a program you should ask for the version you expect. IMO if the auto* developers and Linux distro makers had this attitude then auto* would be in a less parlous state because it would be forced to coexist with other versions of itself. > ln -s /usr/local/bin/aclocal19 /home/gr/bin/aclocal > etc > > This makes the default bootstrap script work. Yeah, "fixing" the bootstrap script isn't really a problem for me so I'll probably just keep a local diff. > Also put "gmake" in place of "make" in the gr-build/buildit script. > FreeBSD defaults to make rather than gmake. Yeah, I usually just type it manually if I get that far ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpd0IpnhRkg7.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Problems building from CVS on FreeBSD
On Mon, 3 Jan 2005 22:43, Daniel O'Connor wrote: > Hi, > I'm trying to build GNU Radio from CVS on FreeBSD -current, but I'm not > having much luck with autoconf and friends :( > > Here's a summary of what I ran.. > aclocal19 -I config > libtoolize15 --automake > automake19 --add-missing > autoconf259 > autoheader259 > > ./configure --with-boost-include-dir=/usr/local/include OK, so round 2.. I nuked auto* and libtools and reinstalled them but I still get the same problem.. [inchoate 15:51] ~/projects/gnuradio/gr-build/gnuradio-core >aclocal19 -I config /usr/X11R6/share/aclocal/xmms.m4:17: warning: underquoted definition of XMMS_TEST_VERSION run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/X11R6/share/aclocal/xmms.m4:62: warning: underquoted definition of AM_PATH_XMMS /usr/X11R6/share/aclocal/wxwin.m4:36: warning: underquoted definition of AM_OPTIONS_WXCONFIG /usr/X11R6/share/aclocal/wxwin.m4:59: warning: underquoted definition of AM_PATH_WXCONFIG /usr/X11R6/share/aclocal/oaf.m4:4: warning: underquoted definition of AM_PATH_OAF /usr/X11R6/share/aclocal/libart.m4:11: warning: underquoted definition of AM_PATH_LIBART /usr/X11R6/share/aclocal/imlib.m4:9: warning: underquoted definition of AM_PATH_IMLIB /usr/X11R6/share/aclocal/imlib.m4:167: warning: underquoted definition of AM_PATH_GDK_IMLIB /usr/X11R6/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK /usr/X11R6/share/aclocal/gdk-pixbuf.m4:12: warning: underquoted definition of AM_PATH_GDK_PIXBUF /usr/X11R6/share/aclocal/gconf-1.m4:4: warning: underquoted definition of AM_PATH_GCONF /usr/X11R6/share/aclocal/gconf-1.m4:71: warning: underquoted definition of AM_GCONF_SOURCE configure.ac:61: warning: AC_PROG_LIBTOOL is m4_require'd but is not m4_defun'd configure.ac:61: AC_PROG_LIBTOOL is required by... config/gr_scripting.m4:30: GR_SCRIPTING is expanded from... configure.ac:61: the top level Argh! What the heck is with auto* *foams at the mouth* -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpYm8YLEVirn.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
On Wed, 11 May 2005 23:49, James Cooley wrote: > In the other window, do: > #> gzip -dcf data.gz > testfifo > > > > Seems to work barely on my laptop, which is a 1.6 GHz pentium M > machine HOWEVER, to aid things along even more, I did the captures > without using X-windows (you don't need it if your not using any guis). > You can switch consoles in linux with ctl-alt-Fx, where F7 is where your > x-windows is running. I switched to a console, killed X, used one > console for the usrp, the other for the piping and zipping. > > How well did it work? I did a sweep of the entire front-end's range, > about 40 minutes of sampling incrementing by 400kHz about every second > from 50 Mhz to 860 MHz... this gave me a zipped file roughly 600MB. It would be interesting to see how well say, FLAC or Shorten work at compressing this stuff. When I did some tests with our radar systems Shorten worked very well, but I suspect FLAC would have worked better if it could have been configured for the right number of channels (ie 300). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpwM0N4kxfov.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
On Thu, 12 May 2005 01:08, cswiger wrote: > Daniel & James (et al) - Firewire or USB drive looks the way to go, > with compression in the stream (Tks James). I've found a world of > 12vdc input ATX power supplies are available, like: > > http://www.orbitmicro.com/products/power%20supplies/dc-dc/ps2/KPDX250H.htm > > might run a small server mobo with big SCSI disk. Not sure "big" and "SCSI" go in the same sentence :) Modern IDE drives to very well at sequential read/writes so they should be very good for this application IMO. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp0tX1WCVkoG.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
On Wed, 11 May 2005 21:43, Chuck Swiger wrote: > for about 3 or 4 minutes each before filling up 20Gb free space. Still it's > nice to collect > field data for later slicing and dicing in the basement. > > Looking for faster/bigger portable storage. The Adaptec SlimSCSI 1480 card > will only do > 20MB/sec. If you can power a mains appliance (car inverter?) you could use an external firewire drive. I doubt you could run a USB enclosure and the USRP without running out of USB bandwidth but firewire should be OK. The enclosures I've used (Mapower) can keep up with WDJB drives which do around 30-50Mbyte/sec. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp7LYNKfyjFY.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB 1 for USRP
On Thu, 28 Apr 2005 05:54, Suvda Myagmar wrote: > I wanted to setup my 2nd USRP hardware on ThinkPad A31p with FC3. All > software packages are set up. But found out that this machine has only > USB 1 ports; USRP works only with USB 2. Without swithing machines, what > can I do? It should _work_ just at really low data rates. You can get USB2.0 Cardbus cards pretty cheaply though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpuixIVPqOl4.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CVS using FreeBSD
On Mon, 4 Apr 2005 00:11, LRK wrote: > On Sat, Apr 02, 2005 at 10:54:14PM -0800, Eric Blossom wrote: > > On Sat, Apr 02, 2005 at 07:11:52PM -0500, Ilia Mirkin wrote: > > > Is there a reason to use bash instead of sh, which is pretty standard > > > across all UNIX-like systems made in the past 15 years or so... > > > > Nope. Should work fine with /bin/sh. > > Dont know if this is FreeBSDism or generic but sh complains about the > "==" and bash doesn't. == is a bashism. = is for string compares. Anyone want a copy of the test(1) man page? ;) > > --- buildit.orig Sun Apr 3 09:20:13 2005 > +++ buildit Sun Apr 3 09:37:47 2005 > @@ -1,7 +1,7 @@ > #!/bin/sh > # -*- shell-script -*- > > -if [ $# -gt 0 -a "$1" == -n ] > +if [ $# -gt 0 -a "$1" = -n ] > then >SUDO= >shift -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpaCpAXscw1m.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
