Re: [Discuss-gnuradio] More sensitivity tests of the USRP2 + Basic_RX
"Marcus D. Leech" writes: > Using the scope display, I measured the detector output difference > between nothing connected (which on the BASIC_RX means that > the A/D is "seeing" the 50-ohm termination across the input-half of > the balun transformer), and my -46dBm signal connected. I see your point and your logic, but this seems to be assuming too much. What if you adjust your signal generator to -110 dBm? That's a fairly low value, but it should be easily acheivable on most RF signal generators. > That difference amounted to a 65dB difference in detected output power. > Doing the math, does that mean that a "naked" > USRP2 + Basic_RX is sensitive down to roughly -111dBm, or should I > factor in root(5KHz), which brings it up to -92dBm. If you're looking at CW, 5 KHz is huge, and probably as you bring down the bandwidth you'll get the same output as long as you're in the passband. This is how ARRL does receiver tests; it's probably at least good to understand how you're differing: http://p1k.arrl.org/~ehare/testproc/testproc.pdf You could probably convince them to run a set of tests on a USRP-based radio, sort of a product review without a product and without really doing the rest of the review. pgpChpbpwu97n.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Muhammad Khan wants to stay in touch on LinkedIn
Jeffrey Lambert writes: > What's up with all the LinkedIN Requests?! linkedin seems to have the same problem as many other services of letting people upload an address book and mass-invite. Everyone should forward invitations received on the list to ab...@linkedin.com, which will cause them to spend at least some time dealing with the problem. pgpSzqzh3NuYE.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 802.11-b project - MAC Layer issue
Doug Geiger writes: > As far as my understanding goes, there is not a complete > implementation of the 802.11b-spec MAC. The files you've found are, to > the best of my knowledge, the only released code out there > implementing a partial MAC (i.e. it performs some carrier-sensing > functions in an attempt to avoid collisions), but I don't believe > anyone has a real, compliant MAC working (or at least has not released > one to the world). In particular, I think making the timing > requirements of the SIFS and DIFS would be extremely difficult to > achieve, although I don't know if anyone has performed any in-depth > latency measurements with the USRP2 as has been done with the USRP1. We have released all the code we wrote for gnuradio/802.11, so there's nothing else out there to get. I never expected us to be able to deal with DIFS/SIFS with the USRP. pgpYlSdh4PSrT.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 802.11b - Identifying blocks, doxygen
Juan Ramon Gutierrez Agullo writes: > Hi all, > > I want to develop 802.11 a from b. I have the BBN 802.11 b code from > CGRAN (https://www.cgran.org/wiki/BBN80211) but it comes without doxygen > documentation or something else. > I'm unable to identify MAC/PHY layer and the flow graphs (for TX and > RX). What files exactly may I have to look? > > Thank you for your help It sounds like you are doing a school project. (perhaps we should have a mailinglist rule that this be clear :-). If so, I would suggest reading and understanding the entire code as the first step. pgpCiB1ET1ppA.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu vs other linux
I'm writing a report on gnu radio and I had a question... I believe most everyone uses Ubuntu compared to other Linux systems for GNU radios why is this? Is it simply because Ubuntu is easier/more user friendly or does it have to do with the way Ubuntu works? You should also realize that GNU Radio runs on systems other than GNU/Linux. I haven't used GNU Radio much lately, but when I did we were running on NetBSD, and I've seen activity for running on Mac OS X. pgp3khtZiIsDv.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [BBN_USRP2] Barker (de)spreading
From my side I decided to spend some more time in understanding why the bbn_802.11_tx.py doesn't work when trying to receive with real 802.11 chipsets in monitor mode (modified to disable the mac CRC check). I am now fuzzy on the details, but I think the basic problem is that the USRP doesn't have enough bandwidth to run at a rate high enough to represent the entire transmitted signal. I am not understanding how you are proposing to get around that. The receive path is basically a hack to work around this, expecting a signal which was to-spec 802.11 received and aliases by a receiver with too low a sampling rate, and then correlating to a representation of an ideal signal as we expect it to be munged by the receive chain. The receive hack does not straightforwardly work on transmit. If you're running at higher speed with fewer samples, you might be getting closer, but if you assume you have to represent 22 MHz of signal, it still seems hard to fit. pgph3EtAXgPOG.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bbn 802.11 problem
Several months ago I installed bbn 802.11 code and got it running. but today when I wanted to download it in my new PC (according to what I've done before http://gnuradio.org/trac/wiki/OtherCode) cvs -d anon...@acert.ir.bbn.com:/cvs/adroitgrdevel co adroitgrdevel the problem is cvs checkout: Updating adroitgrdevel cvs [checkout aborted]: cannot stat /var/lock/cvs/adroitgrdevel: No such file or directory cvs [checkout aborted]: cannot stat /var/lock/cvs/adroitgrdevel: No such file or directory Sorry, I cleaned up what I thought was crud on the server because /var got full, and obviously (now) these dirs don't get autocreated as needed. I have fixed them and verified that a checkout works. The command above is right, or at least worked for me. That said, the code is getting a bit crufty and I had the impression there was a spiffed-up version of it on CGRAN. I have not had time to hack on this lately. pgpkUUJ4L48sw.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code for current release (3.1.3)?
2) Why doesn't gnu radio team include BBN 802.11 code in their office release, just same as what they have done to the m-block codes? Then these codes would be better maintained and utilized. The BBN code has copyright assigned to FSF, so it's just a question of somebody doing the integration work. 3) BBN 802.11 codes are only compatitable with some older version of gnu radio (v3.1.1). If I have to use the lower version gnu radio in order to utilize the bbn 802.11 codes, what power and functionality I will lose from not using the new current ralease. Is this an acceptable alternative? Maybe I can not use the new USRP2 boards since they are just newly released and probably not supported by the older version gnu radio. what else? people are adapting the code for newer versions. In my opinion it's not reasonable to stay at old gnuradio versions. 4) Most people who need BBN 802.11 PHY codes also need to work on MAC layer, mostly working on Click modular router. As I saw in some papers, BBN also implmented two APIs (an MAC-Subnet API for Click to use to talk to the MAC layer, and aonther Radio API for MAC layer to talk to the GNU Radio) and a model MAC in Click. They are supposed to be open-sourced. Have you used them or know where to find them? These were mostly designed, but not implemented. Our project was intended to go 3 years but stopped after only one. pgp8NwrgRcdqH.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiler preprocessor defines
Eric Blossom <[EMAIL PROTECTED]> writes: > On Mon, Nov 03, 2008 at 03:46:56PM -0500, Ed Criscuolo wrote: >> The tun/tap pseudo device is implemented very differently >> on OSX vs LINUX, UNIX, et al. > > OK. > > Take a look at how we handle the "Fast USB" technique selection. > See config/usrp_fusb_tech.m4. > > It would probably be a good idea to abstract the whole "open the > tap/tun device" operation into a separate function, then swig it up so > that it's accessible from python. Ed: while you are working on this, it would be good to plan for N different implementations of user-space tunneling network interfaces rather than 2. I suspect that most of *BSD is similar, and I've enclosed the NetBSD man pages. Darwin may or may not be like *BSD; they seem to do things in the Apple way sometimes, but from your description it seems similar. I would have code that handles each major API, and then select which api with autoconf tests, looking for api-specific ioctls being defined in headers, and relying on OS names as a last resort. I have enclosed net/if_tap.h from NetBSD which defines the TAPGIFNAME ioctl. TAP(4) NetBSD Kernel Interfaces Manual TAP(4) NAME tap -- virtual Ethernet device SYNOPSIS pseudo-device tap DESCRIPTION The tap driver allows the creation and use of virtual Ethernet devices. Those interfaces appear just as any real Ethernet NIC to the kernel, but can also be accessed by userland through a character device node in order to read frames being sent by the system or to inject frames. In that respect it is very similar to what tun(4) provides, but the added Ethernet layer allows easy integration with machine emulators or virtual Ethernet networks through the use of bridge(4) with tunneling. INTERFACE CREATION Interfaces may be created in two different ways: using the ifconfig(8) create command with a specified device number, or its ioctl(2) equiva- lent, SIOCIFCREATE, or using the special cloning device /dev/tap. The former works the same as any other cloning network interface: the administrator can create and destroy interfaces at any time, notably at boot time. This is the easiest way of combining tap and bridge(4). Later, userland will actually access the interfaces through the specific device nodes /dev/tapN. The latter is aimed at applications that need a virtual Ethernet device for the duration of their execution. A new interface is created at the opening of /dev/tap, and is later destroyed when the last process using the file descriptor closes it. CHARACTER DEVICES Whether the tap devices are accessed through the special cloning device /dev/tap or through the specific devices /dev/tapN, the possible actions to control the matching interface are the same. When using /dev/tap though, as the interface is created on-the-fly, its name is not known immediately by the application. Therefore the TAPGIFNAME ioctl is provided. It should be the first action an applica- tion using the special cloning device will do. It takes a pointer to a struct ifreq as an argument. Ethernet frames sent out by the kernel on a tap interface can be obtained by the controlling application with read(2). It can also inject frames in the kernel with write(2). There is absolutely no validation of the content of the injected frame, it can be any data, of any length. One call of write(2) will inject a single frame in the kernel, as one call of read(2) will retrieve a single frame from the queue, to the extent of the provided buffer. If the buffer is not large enough, the frame will be truncated. tap character devices support the FIONREAD ioctl which returns the size of the next available frame, or 0 if there is no available frame in the queue. They also support non-blocking I/O through the FIONBIO ioctl. In that mode, EWOULDBLOCK is returned by read(2) when no data is available. Asynchronous I/O is supported through the FIOASYNC, FIOSETOWN, and FIOGETOWN ioctls. The first will enable SIGIO generation, while the two other configure the process group that will receive the signal when data is ready. Synchronisation may also be achieved through the use of select(2), poll(2), or kevent(2). ETHERNET ADDRESS When a tap device is created, it is assigned an Ethernet address of the form f2:0b:a4:xx:xx:xx. This address can later be changed in two ways: through a sysctl node, or an ioctl call. The sysctl node is net.link.tap.. Any string of six colon-sepa- rated hexadecimal numbers will be accepted. Reading that node will pro- vide a string representation of the current Ethernet address. The address can also be changed with the SIOCSIFPHYADDR ioctl, which is used the same way as wit
Re: [Discuss-gnuradio] updated BBN 80211 code?
Eric Blossom <[EMAIL PROTECTED]> writes: > Let me try that without adding anything else: > > All code in the gnuradio.org svn repository shall be GPL and > assigned to FSF. Just to stir the pot: it's the copyright holder that chooses the license. So it's really (Note that the GNU Radio project is a sub-organization of the FSF.) All code in the gnuradio.org svn repository shall be assigned to FSF. (Because the GNU Radio project has a policy that says it can't go in unless it is assigned) GNU Radio Project has a policy that all of its code will be GPL. Practically, people with assignments put the GPL markings on, but they are following project policy when doing so, not making a license choice. pgpLrczT3vaIe.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: forced GPL in CGRAN? gr-ucla code in BBN repo not GPL?
[Discussion about gr-ucla's BSD license and GPLv3 compatibility.] http://www.gnu.org/licenses/gpl-3.0.html http://www.softwarefreedom.org/resources/2008/compliance-guide.html I have looked at these. UCLA has placed code under a 3-clause BSD licenes. As far as I understand, that's a "GPL compatible non-copyleft free software license" under the FSF taxonomy, and there's no problem linking that code with GPLv3 code. See http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses and search for "modified BSD licenes". Anything that includes any gr_*.h header directly or indirectly is going to be a "work based on the earlier work" and must be licensed under the GPL. This seems to be the FSF's interpretation; I'm not the least bit sure that's settled copyright law. One can't use text in the GPL to decide what meets the derived work test under copyright law. Including a header and calling functions does not in my view make the source file a derived work, but IANAL. If one distributes a combined work -- and none of Thomas, UCLA, or BBN have done so, to my knowledge -- then in order to have permission to redistribute the GR parts, the distributor has to be able to grant permission to copy the entire source under GPL. The BSD license grants adequate permission to do that, which is why it's considered GPL-compatible, so there's no issue doing that. But, just because someone distributes the code under the GPL doesn't mean others can't go back to the original BSD-licensed code and copy it under those terms. Stepping way back from law, DARPA funded research and wanted the results to be broadly available, under a BSD license rather than GPL, in order to ease tech transfer (in ways the FSF objects to, by enabling proprietary derivative works). BBN's GNU Radio work is assigned and hence GPL, because we tried to meet each community on its own terms. UCLA has a more permissive license, and I think that's fine too. The important thing is that others in the community have the ability to modify, improve, and redistribute the code, and the BSD license certainly permits that. So I don't think there is actually any problem at all. pgpunGATSdXFL.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code?
For me, I don't think this is a problem - as I've just recently submitted my assignment for patches to gnuradio. So as long as the BBN code is considered part of gnuradio - it should fall under that (as far as I understand my assignment statement). Either way, if the code gets hosted somewhere, I'll be happy to send in what I have. It does look like I'm going to have to re-create some of my work though - too many changes since this past summer and apparently I wasn't good about saving a version that worked. As for the larger question about CGRAN, I think it makes sense as a third-party repository, but I can imagine that might lead to problems down the line for anything that might be desirable for inclusion into the mainline gnuradio repository. Great - in that case if you take the BBN code, beat on it, and get it in the main repo that would be great. It's fine with me if it goes in CGRAN instead, but if it does I would want there to be clean history so the later questions of ownership could be settled. But still it's better to have something that works with modern GNU Radio than not. Responding to George, having CGRAN as a way to publish code that hasn't yet been fully integrated, due to lack of Copious Spare Time or lack of assignment, sounds like a good plan to me. The ACERT server is more or less functioning this way for the BBN 802.11 code and the gr-ucla code. pgpfH8JEGYIyf.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: forced GPL in CGRAN? gr-ucla code in BBN repo not GPL?
I request that anybody that has questions or comments about any of this first take the time to read the text of the GPL and the compliance guide before posting (links at the top). It'll save us all a lot of time. Fair enough, but two observations: my memory is that GNU Radio switching to GPLv3 happened long after all the gr-ucla code was written. the exact boundaries of derived work is not a settled question All that said, I agree with your points about mixed licensing being awkward at best. pgpaAEJLe0QbW.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code?
George Nychis <[EMAIL PROTECTED]> writes: > George Nychis wrote: > >> >> Another alternative is it residing in CGRAN for Doug and Dustin to >> update it to work with the current trunk, and once complete it can >> be integrated in to the main GR repo by you or whoever. >> > > Side note, how does this work with FSF copyright? If someone develops > something outside of the GR repo, and then you want to integrate it. > Do you need an FSF copyright from them to pull in their code that is > already under GPLv3? I didn't get around to answering George's question from last night about the BBN code in private mail before I aaw this, so I'll answer here: The BBN 802.11 code (there is no 802.11b code) has had the copyright assigned to the FSF, so it can go in the real repository. It is licensed under the GPL (by the FSF, technically), so there's no legal reason you can't put it in CGRAN. I don't mind - it was written to be used by the community. But I think we should slow down and sort out the copyright assignment plan. The real question is how CGRAN and gnuradio.org relate. GNU Radio's policy is that all code in gnuradio.org must be copyrighted by the FSF. The BBN code on the BBN server is clean in this regard, since it's all work-for-hire on my project by BBNers, and thus the single copyright assignment contract covers it all. As soon as it's put on CGRAN and others start hacking, the list of peeole who need assignments on file to be able to move it into gnuradio.org grows, and it gets harder. So I think the top-level question is whether CGRAN is for code that isn't assigned. I think that's the only thing that makes sense; people with assignments can more or less work directly in the gnuradio.org repository. There's another, much harder question, about whether the all-code-must-be-assigned stance is optimal. It certainly discourages contributions, but ends up with a clearer legal status. But that's entirely separate from "given the assignment rule, what should be the plan for CGRAN". pgpNLq3q8kSKL.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Important: New trunk dependency: GSL
I'll be adding the GNU Scientific Library (GSL) as a new dependency on the trunk. GSL is a huge numerical library that's been under active development for more than 10 years: http://www.gnu.org/software/gsl FYI this is in pkgsrc as math/gsl and it's at 1.11. pgp7l7KkpdYAx.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 802.11 bbn_80211b_rx.py
BTW, what does that guy mean "Not sure when you updated, but we have changed the checked in code to default to 2437, and run it like this (as a NetBSD rc.d start script)", following the above link? details if you care, but surely they have little to do with your issues. http://www.netbsd.org/docs/guide/en/chap-rc.html about your output: ./bbn_80211b_rx.py -f 2.437G -v -b Bits Per Encoded Sample = 8 adc frequency = 6400 decimation frequency = 16 input_rate = 400 gain = 45.0 desired freq = 243700.0 baseband frequency 243200.0 dxc frequency -500.0 Samples per data bit = 8 >>> gr_fir_ccf: using SSE 2.432G is used instead of 2.437G. Also the dxc frequency is negative. And no packets get printed out. I am unclear on dxc. Are you sure there are strong signals at the 1 Mb/s rate on 2437 MHz? /adroitgrdevel/gr-bbn/src/examples/bbn_80211b_rx.py just like this: What operating system are you running on? That script may be expecting the NetBSD tap device, and your system's might be different. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 802.11 bbn_80211b_rx.py
BTW, what does that guy mean "Not sure when you updated, but we have changed the checked in code to default to 2437, and run it like this (as a NetBSD rc.d start script)", following the above link? It means there is somewhere checked in a script that fits into the NetBSD rc.d framework so that GNU Radio is started at boot time. Our code expected to stuff received packets into a tap(4) device. I would suggest digging into the code a bit and adding some debug print statements. (If you aren't comfortable doing that, this code isn't for you!) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using USRP/GNURADIO Commercially
"Jeff Brower" <[EMAIL PROTECTED]> writes: > Joel- > > Your question doesn't make sense to me. If your clients pay you to > develop source code that derives from, or partially incorporates, GPL > licensed code then they own the developed source, not you. They are > responsible for license issues with the newly developed code. This is getting way off topic, but this is incorrect (assuming we are talking in the US). Look up the "work for hire" doctrine in copyright law. Absent a written agreement, the general notion is the clients do not hold copyright, but employers do. sort of on topic: This is why the FSF asks for a disclaimer from employers that code is not within the scope of employment. My GNU Radio changes, and that of my project team, are assigned to FSF, but the assignment is from BBN since those were changes made by employees (and done "within the scope of employment"). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio and GPL licensing issues (again)
First, you seem to be in need of actual legal advice from someone qualified and licensed to provide it. Your question has a serious misconception, that code has a single license. The GPL cannot require that other code be under the GPL; it can only prohibit distribution of a derived work unless some conditions are met. Typically this is "in order to distribute the derived work from GPL component foo, you must also distribute the entire source code for the derived work under the GPL". However, there is no reason why you cannot have work bar (all of which you wrote), and GPL work foo, and link them to a derived work baz, and then distribute baz and bar under the GPL, and also (not instead) distribute bar under some other license, such as "If you pay us $10K you can do whatever you want". The point is that code being available under the GPL does not prevent or prohibit proprietary derived works; it's the lack of availability under a proprietary-compatible license that prohibits that. The issue of whether the source code of a program that #include's header files and expects to link against libraries (where the headers/library are GPL only) is a derived work is a murky question, and here you are particularly in need of actual legal advice. My current impression is that there is not settled case law in this area, but IANAL, TINLA. If you are an RA, the university may hold copyright under the work-for-hire doctrine, and I would advise resolving all these issues before the code is written. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: 802.11 on USRP+GNURadio
We've had similar issues. Please see our 802.11 receiver implementation: http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver Indeed - you should definitely try the others. Ours sort of works, and has a c ool hack to fit within USRP USB bus bandwidth, but I expect implementations that deal with some things on the USRP side to have substantially better performance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 802.11 on USRP+GNURadio
Looking at the archives, I understand that I can receive 1 Mbps probe/beacon packets with code developed by BBN. I use their code and see packets at 1 Mbps from different nodes. However, I don't know of a way to have the USRP as a destination for a flow using standard packet generation tools like Iperf. So I setup a We wrote code to inject the packets (802.11 frames) into a modified NetBSD tap device that was an 802.11 interface rather than ethernet, and then were able to use tcpdump. All of this code is on the acert.ir.bbn.com server. We didn't address all the interactions with the 802.11 state machines in net80211 and the GNU Radio implementation. So you should be able to port this to Linux, but it's non-trivial. UDP flow between a conventional 802.11bg AP and a Laptop. I capture the packets on air with the USRP and determine how many of the packets of this flow I am able to receive. But here, out of 1000 packets (1500 bytes each) sent at 1 Mbps, the laptop is able to receive around 900 packets but the USRP captures somewhere between 100 to 550 packets. I If the laptop is only gettinng 900, that indicates something is wrong. Are you sending these back to back as fast as you can? I'd back off to 200 pps or something like that, and see what happens, and then gradually increase the rate, watching CPU load. am wondering whether this makes sense. I thought that the BBN code would capture most of the packets provided the rate is 1 Mbps (disregarding probe packets from other APs). But this does not seem to happen.. We did get most packets given a reasonable load I use gnuradio-3.1.2 on Ubuntu Dapper with a 2 GHz Intel core duo processor and 2 GB RAM. We had 1.6 GHz Pentium M with 2 GB RAM (Thinkpad T43), with NetBSD current from summer 2006 (pre 4.0). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
"Pu, Di" <[EMAIL PROTECTED]> writes: > I am trying to figure out the Matlab interface to USRP. Although I > could enable the communications between Matlab and GNU Radio, I am > wondering whether it is possible to make Matlab hook to USRP directly > without GNU radio. Thank you very much! (This isn't entirely directed at you - there has been discussion of proprietary software recently, and I know from private correspondence that several others share the views below. Thus, I thought it helpful to air them.) My impression is that the charter of the list is to advance GNU Radio as a Free software implementation of SDR, within the context of a larger effort to have enough Free software so that we don't need to use any proprietary software. Although I don't see this notion on the wiki, it's the normal notion for lists associated with official GNU projects of the FSF. If you're interested in using the USRP with proprietary software like Matlab, I would suggest also asking on some Matlab user's list. I believe that a number of the more clueful people on this list are philosophically disinclined to volunteer to help people use proprietary software. There has been some recent discussion about using Free software that has matlab-like features, like octave and freemat. http://www.gnu.org/software/octave/ http://freemat.sourceforge.net/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] execute MATLAB code with mlab_call
Dev Ramudit <[EMAIL PROTECTED]> writes: >> I wonder if you could make this work with octave. MATLAB is decidedly >> non-Free, and thus I'd expect that any support to interoperate with >> MATLAB probably wouldn't be eligble for integration into the tree. >> >> How do you link this in such a way that you can follow the GPL and >> distribute it? > > It seems like octave has a similar interface > (http://wiki.octave.org/wiki.pl?CategoryExternal under OctaveEngine), > which could be used in a way very similar to the code I have. > > I know that there exists other projects under open licenses that use > the MATLAB engine API (pylab, mlabwrap, ruby-matlab, etc.). I'm not > well versed in licensing issues, but reading through the MATLAB > software license I don't see any issues with linking to the shared > objects the interface provides. I'm very inexperienced in this area, > so please let me know if I'm incorrect. There are several issues. One is following the proprietary program's license, and another is complying with the GPL, which requires that all of any derivative work be licensed under the GPL. Then, there's the cultural issue of accomodating non-Free software within the context of a Free Software project. Many people believe that it's not helpfully on the path to a world where we can do everything we want with Free software, and that seems to be more or less the view of the FSF. Of course it depends on your goals, but I thought I should point out this issue. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] execute MATLAB code with mlab_call
I've been working with a colleague who works mostly in MATLAB to prototype and test the work we're doing, so I've written a block that uses the MATLAB engine interface to execute MATLAB code as part of a flowgraph. It's based on the howto-write-a-block example, and can be built and used in much the same way. Please let me know if you find this block useful and if you needs other versions (for floats, etc.). If you're interested in using this block, please follow the README. I wonder if you could make this work with octave. MATLAB is decidedly non-Free, and thus I'd expect that any support to interoperate with MATLAB probably wouldn't be eligble for integration into the tree. How do you link this in such a way that you can follow the GPL and distribute it? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a call for a better wiki
My take is that after we have some content, and it becomes too much to be listed on the front page, then it will make sense to have more organized intro pages. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RANDOM_MAX
In gnuradio-core/src/lib/general/random.h, RNADOM_MAX is defined unconditionally: Recently NetBSD-current has added RANDOM_MAX, for essentially the same reason, to parallel with RAND_MAX. (random(3)'s definition is 0 to 2**31-1, so this shouldn't be different). So, is it ok to commit this patch? I would also update the comment (it's not a bug that Solaris RAND_MAX is 32767 if rand(3) on Solaris returns from 0 to 2**15-1 - standards don't require 2**31-1 that I know of)? $NetBSD: patch-ag,v 1.3 2008/03/15 15:09:54 joerg Exp $ --- gnuradio-core/src/lib/general/random.h.orig 2008-03-15 15:34:46.0 +0 100 +++ gnuradio-core/src/lib/general/random.h @@ -24,8 +24,9 @@ #define _RANDOM_H_ // we use this because some systems (solaris) define RAND_MAX as 32767 - +#ifndef RANDOM_MAX static const int RANDOM_MAX = 2147483647; +#endif #include ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.1.2rc0 tarballs available for testing
"Johnathan Corgan" <[EMAIL PROTECTED]> writes: > On 3/15/08, Greg Troxel <[EMAIL PROTECTED]> wrote: > >> See README.components for how to deal with this. This splits all of the >> pieces of GNU Radio into independent builds. It probably does not make >> sense to have one pkgsrc package per component, and probably >> "gnuradio-core" should have a bunch of components in it. Basically, I >> see no reason for someone to want to install pmt but not gnuradio-core - >> the real reason to split is to avoid depdendencies or huge things. > > BTW, the README.components script is in the trunk only, not part of > the regular release. The build dependencies of the trunk are > substantially different and the script would not work for the 3.1.2 Sorry, I was confused about what was in the release candidate and Berndt's build troubles caused me to jump to the wrong conclusion. > release. In case anyone is wondering, this script is an example of > an *alternative* way to build GNU Radio, primarily of interest to *BSD > users. Just to clarify a bit: The alternative fine-grained build (besides being useful for ensuring the build procedure is squeaky-clean) is aimed at packaging systems that want to make a number of packages from one source tarball and do so with multiple separate builds, rather than one build and then having N separate lists of files. For build GNU Radio from svn as a regular user rather than package maintainer on *BSD, the existing build system works fine. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.1.2rc0 tarballs available for testing
The svn comment is harmless; it's a side effect of using a tarball instead of an svn checked out source tree. Why does configure look for svn at all? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.1.2rc0 tarballs available for testing
BTW: Which package does provide libgromnithread? See README.components for how to deal with this. This splits all of the pieces of GNU Radio into independent builds. It probably does not make sense to have one pkgsrc package per component, and probably "gnuradio-core" should have a bunch of components in it. Basically, I see no reason for someone to want to install pmt but not gnuradio-core - the real reason to split is to avoid depdendencies or huge things. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] captuting 20MHz signal
Has there been any successes regarding WiFi implementation with higher bandwidths (upto 20MHz)?... (Your email was not line-wrapped and I fixed it.) The BBN 802.11 implementation received 1 Mb/s fairly reliably and 2 Mb/s spottily. I don't think we ever got 11 Mb/s working. A 20 MHz signal sounds pretty difficult. Note that at 16M complex you are talking 8 bit samples. I would suggest waiting for the USRP2 :-) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio & USRP with OpenBSD anyone?
GNU Radio builds fine on NetBSD, and only minor fixes were needed to get it to that point. So it shouldn't be that hard to make it work on OpenBSD. I realize you are probably using OpenBSD ports and not pkgsrc, but there is a pkg_chk.conf file in the root directory of gnuradio that lists what is required - not sure if you're having trouble with prereqs or the actual build. NetBSD 4 and current has improvements to ugen(4) that greatly improve performance. You may wish to port these to OpenBSD if you're going to use a USRP. I would recommend that you start with the head from svn, and either run README.components (after reading it!) or try a regular build. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] use of -D in install??
Thanks for catching the typo - committed and a new README.components build started. -D on NetBSD is about stripping DESTDIR from pathnames logged to METALOG for unpriveleged installs - and it takes an argument. The use of automakes dir/data declaratoin is simpler anyway. I am now able to build pretty much everything except gr-comedi (no comedi lib on my system) and some gr-audio-* components, just by running README.components. I'd be curious to see if it works ok on Linux or other systems. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] use of -D in install??
gr-gpio won't install on NetBSD because the Makefile.am uses the -D option to install, and BSD install doesn't have -D. I tried to find a man page for the GNU version, but didn't manage to. The following fixes the problem, and moves this back closer to standard automake. OK to commit, or am I overlooking some reason why -D is useful? Index: gr-gpio/src/fpga/top/Makefile.am === --- gr-gpio/src/fpga/top/Makefile.am(revision 7721) +++ gr-gpio/src/fpga/top/Makefile.am(working copy) @@ -23,6 +23,14 @@ datadir = $(prefix)/share/usrp +datarev2dir = $(datadir)/rev2 + +datarev4dir = $(datadir)/rev2 + +datarev2_DATA = usrp_gpio.rbf + +datarev4_DATA = usrp_gpio.rbf + RBFS = usrp_gpio.rbf EXTRA_DIST = \ @@ -35,23 +43,6 @@ usrp_gpio.v \ $(RBFS) -install-data-local: - @for file in $(RBFS); do \ - echo "$(INSTALL_DATA) -D $(srcdir)/$$file $(DESTDIR)$(datadir)/rev2/$$file"; \ - $(INSTALL_DATA) -D $(srcdir)/$$file $(DESTDIR)$(datadir)/rev2/$$file; \ - echo "$(INSTALL_DATA) -D $(srcdir)/$$file $(DESTDIR)$(datadir)/rev4/$$file"; \ - $(INSTALL_DATA) -D $(srcdir)/$$file $(DESTDIR)$(datadir)/rev4/$$file; \ - done - -uninstall-local: - @for file in $(RBFS); do \ - echo "$(RM) $(DESTDIR)$(datadir)/rev2/$$file"; \ - $(RM) $(DESTDIR)$(datadir)/rev2/$$file; \ - echo "$(RM) $(DESTDIR)$(datadir)/rev4/$$file"; \ - $(RM) $(DESTDIR)$(datadir)/rev4/$$file; \ - done - - MOSTLYCLEANFILES = \ db/*\ *.rpt \ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New build system features
rereading, I see this: --with-omnithread Use package omnithread if installed in $prefix/lib/pkgconfig; otherwise revert back to --enable-omnithread --with-gnuradio-coreUse package gnuradio-core if installed in $prefix/lib/pkgconfig; otherwise revert back to --enable-gnuradio-core from a pkgsrc point of view, I'd like to see this be use it from --prefix, and fail if not there. the 'build it if not there' does not serve the cause of repeatable builds, where things go exactly as planned, or you notice. But, I realize that packaging systems may not be the only client. It would be nice if needed and disabled things were just looked for in prefix, and an error if not present, but I haven't really pondered all the use cases. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New build system features
I'm trying to do a build of all the pieces separately, to mimic what
pkgsrc would do. Here's my script, which seems to build omnithread N
times. I'm a bit tired so may be overlooking something obvious:
The bug seems to be that I'm not specifying where omnithread comes from
during the core build, but it's in --prefix, and the wiki page
http://gnuradio.org/trac/wiki/BuildConfiguration didn't seem to explain.
[build log excerpt; full 250 KB on request]
Component omnithread passed configuration checks, but not building.
Component gnuradio-core requires omnithread, which is not being built or
specified via pre-installed files.
configure: error: Component gnuradio-core has errors, stopping.
make all-recursive
Making all in config
Making all in omnithread
Making install in config
Making install in omnithread
test -z "/usr/adroit/lib" || .././install-sh -c -d "/usr/adroit/lib"
/bin/ksh ../libtool --mode=install /usr/bin/install -c 'libgromnithread.la'
'/usr/adroit/lib/libgromnithread.la'
/usr/bin/install -c .libs/libgromnithread.so.0.0
/usr/adroit/lib/libgromnithread.so.0.0
(cd /usr/adroit/lib && { ln -s -f libgromnithread.so.0.0 libgromnithread.so.0
|| { rm -f libgromnithread.so.0 && ln -s libgromnithread.so.0.0
libgromnithread.so.0; }; })
(cd /usr/adroit/lib && { ln -s -f libgromnithread.so.0.0 libgromnithread.so ||
{ rm -f libgromnithread.so && ln -s libgromnithread.so.0.0 libgromnithread.so;
}; })
/usr/bin/install -c .libs/libgromnithread.lai /usr/adroit/lib/libgromnithread.la
build script follows:
#!/binhttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN code-Failed to set Tx frequency to 2.4G
DiX <[EMAIL PROTECTED]> writes: > Mohammad Hamed Firooz wrote: >> I've tried to use BBN code to transmit 802.11 packets by using RFX2400 >> dautherboard. When I run "bbn_80211b_tx.py" I get the following message: >> >> It seems that BBN codes doesnot work with MIMO dautherboards, has >> anybody else had the same problem? Is there anybody who can run BBN >> transmitter code using MIMO RFX2400 daughterboard? > > At least the rx path should work. I use the wireless card to generate the > packet instead of using bbn tx path. In fact I don't think I ever used the > USRP to generate any well shaped .11b packets. Note that the USRP doesn't really have enough bandwidth to create well-formed 802.11 packets. The TX path never really worked. As for receive, we didn't have any MIMO boards. I would suspect that it isn't that hard to fix the code if it indeed doesn't work. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 80211b problem
I am using bbn_80211b_rx.py code and I am getting error No module named bbn_80211b_pkt I think, I don't have the above mention module. can some one tell me where I can find this module. It's in the same directory as the file you mentioned: acert-netbsd gdt 9 ~/ADROIT-public/adroitgrdevel/gr-bbn > find . -name bbn_80211b\* ./src/examples/bbn_80211b.py ./src/examples/bbn_80211b_pkt.py ./src/examples/bbn_80211b_rx.py ./src/examples/bbn_80211b_tap.py ./src/examples/bbn_80211b_test.py ./src/examples/bbn_80211b_transmit_path.py ./src/examples/bbn_80211b_tx.py This code is set up to install the .py files (see Makefile.am): grpythondir = $(pythondir)/gnuradio python_SCRIPTS = \ bbn_80211b.py \ bbn_80211b_pkt.py \ bbn_80211b_rx.py \ bbn_80211b_tap.py \ bbn_80211b_test.py \ bbn_80211b_transmit_path.py \ bbn_80211b_tx.py so if you want to run it not installed you probably have to put the src dir or . in PYTHONPATH. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with 2Mbps of BBN code(802.11b)
We found that 1 Mb/s reception was fairly reliable and that 2 Mb/s was not. I would suggest that you log all the bits and then compare them to the bits as received by a regular receiver and see how far off they are. The CRC being different just means they are different - it doesn't let you distinguish between 1 or 2 bits off and half of them being off. There might well be bugs in the 2 Mb/s code. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN module
I think the answer you want is: cvs -d [EMAIL PROTECTED]:/cvs/adroitgrdevel co adroitgrdevel then ./bootstrap && ./configure as you wish from the gr-bbn subdirectory. Thanks. Snarfed into: http://gnuradio.org/trac/wiki/OtherCode ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN module
Mohammad Hamed Firooz <[EMAIL PROTECTED]> writes: > Hi everyone, > I am going to use BBN code on IEEE802.11b. But these codes need to > import a module named bbn from gnuradio package. My gnuradio has not > this module. Where can I find it and how I can add it to my gnuradio > package. Several people have gotten this to more or less work. It's hard to help unless you describe precisely what you've done. Presumably you have found the code, but if not: http://www.gnuradio.org/trac/wiki/BBN_Technologies_Internetwork_Research_ADROIT_Project ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Removing '.py' from system path installed Python scripts
Frank Brickle <[EMAIL PROTECTED]> writes: >> Given that new versions of python can be installed and made default >> (meaning invoked as 'python'), it's necessary to bind the scripts to the >> same version of python used to build .so modules and install .py files >> in site-packages... > > I'm curious -- really just curious -- why not create a chroot > environment for gnuradio? Or, where the kernel and the CPU allow, > a fully virtualized stable OS install simply for gnuradio? You could, but a chroot per package would lead to a vast number of chroots, and it wouldn't solve the underlying problem of maintaining dependencies. If one views the computer's sole purpose as providing a way to run Gnu Radio, that might be reasonable. If one views GNU Radio as one of many components in an overall system - for instance providing the low-level network connectivity, then it isn't reasonable. The lack of python binding really is just plain suboptimal (or wrong) - but becaues most people rarely change python bindings, and because GNU Radio hackers constantly rebuild/reinstall GNU Radio, it hardly ever causes trouble. I don't expect other people to fix this if they don't want to spend the effort. pkgsrc currently works around this by having a list of files in which the interpreter is changed as they are installed. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Removing '.py' from system path installed Python scripts
Johnathan Corgan <[EMAIL PROTECTED]> writes: > Greg Troxel wrote: > >> But that will only really work if the version of python found as >> 'python' is the same one as the version gnuradio found when it was >> compiled, and the packaging system installs an interpreter as python. >> In a world with multiple python versions and site-libs this leads to >> incorrect behavior. > > True. When someone downloads GNU Radio as a tarball, runs configure, > make, etc., and installs it, everything gets put into the right place to > be used with the version of Python discovered on the path. This is a > good thing, I think, as it covers the most common case. The case where there is no interpreter called 'python', but one called 'python2.4' is not handled. This is how pkgsrc works, specifically avoiding providing 'python', which would change if a new version is instaled. I realize that whether this is reasonable is a tough call. >> See http://www.gnuradio.org/trac/ticket/151 > > Understood. There really isn't a clean solution to this, however. I'd > be happy if could figure out one that doesn't make the common case more > difficult. Given that new versions of python can be installed and made default (meaning invoked as 'python'), it's necessary to bind the scripts to the same version of python used to build .so modules and install .py files in site-packages. I think it can be done quite cleanly by either of the two methods in the ticket, in the software engineering aesthetics sense, and that the modify-on-install avoids a lot of non-local hair. Specifically, add a new script install-py that is generated from install-py.in via configure that has #!/bin/sh # really this might need to parse install args better INSTALLTMP=/tmp/$1.install.$$ sed -e "s,/usr/bin/env python,@PYTHON@," < $1 > $INSTALLTMP install -m 555 $INSTALLTMP $2 and then have the install-script rule use this instead. I looked in the tree, and it seems it should go at top level alongside py-compile. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Removing '.py' from system path installed Python scripts
Removing the '.py' works fine on OSX 10.4.10, so long as the file is executable (a+x) and has "#!/usr/bin/env python" as the first line to get the runtime environment correct. - MLD Agreed. But that will only really work if the version of python found as 'python' is the same one as the version gnuradio found when it was compiled, and the packaging system installs an interpreter as python. In a world with multiple python versions and site-libs this leads to incorrect behavior. See http://www.gnuradio.org/trac/ticket/151 This is an orthogonal issue to the renaming, so I don't mean to object, and I haven't written an install script to change #!/usr/bin/env python to [EMAIL PROTECTED]@ when doing the install, so it's fair to say ENOPATCH to my mail. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Removing '.py' from system path installed Python scripts
However, a common convention on Linux, at least on Debian, Ubuntu, and derived systems (probably Redhat too), is to strip the language specific extension off scripts in the path. Would anyone have any heartache if we did this for the gr-utils scripts as well as the relatively few other scripts we install on the path? usrp_fft.py -> usrp_fft usrp_rx_cfile.py -> usrp_rx_cfile >From the NetBSD viewpoint, I think that's perfectly fine. It would be good if all the scripts started with a small set of prefixes like usrp_foo and gr_foo, to avoid collisions with at least most of the other 5000 packages. Sounds like you are headed this way. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why is Barker Spreading difficult to usrp?
DiX <[EMAIL PROTECTED]> writes: >With BBN codes and FLEX2400 d'borads, now I can received 802.11b > packets from standard wireless cards, and communicate between two USRPs with > barker spreading off. These make me really excited :) That's good to hear - that matches where we got to. >However, I failed trying to send any packet from USRP to PC. I > believe it is because the barker spreading of thej tx path was not working > well and PC could not interpret the packets correctly. I also sent packets > between USRP with barker on. That did not work too. I am not sure if we ever thought that we had the barker transmit working. >It seems barker demodulator works but modulator does not. Why is the > barker spreading difficult for usrp? Is it because the 1MSps symbol rate is > too tough for the USRP board? ( USRP is not that fast to deal with 1 > million 11-bit batter sequence?) It's because the bandwidth of the signal from 1 Msample/s times 11 chip/symbol is 11 Mchip/s. I think we used 8-bit i/q and 8 Msample/s to get 16 MB/s across the USB. For the barker receiver, the code computes pre-distorted waveforms of the barker code. I don't know that the transmitter does, but really I think it just has to hope for the best in terms of the receiver receiving a distorted signal. You may be able to up the rate to 32 MB/s (16 Msample/sec) and tx may work better. Or, you could implement the barker code in the fpga. The BBN code is assigned to FSF, so you are welcome to integrate it into GNU Radio proper. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] head builds on NetBSD
Perhaps this shouldn't be news, but I have been busy with other things and haven't tried to build GNU Radio in a long time, so I thought I'd try it and see if anything needed fixing. I just did a build of the head of svn on a system that's basically the old 4.0 branch from last january and it built just fine. I did have to clean out a lot of .deps files - just updating and rerunning the autotools stuff cause the link to fail. But after pruning all was well. This was with: CONF_COMPONENT_ARGS=" --disable-all-components \ --enable-omnithread \ --enable-gnuradio-core \ --enable-usrp \ --enable-gr-usrp \ --disable-gr-audio-alsa \ --disable-gr-audio-jack \ --enable-gr-audio-oss \ --disable-gr-audio-osx \ --disable-gr-audio-portaudio \ --disable-gr-audio-windows \ --disable-gr-atsc \ --disable-gr-comedi \ --disable-gr-gsm-fr-vocoder \ --disable-gr-radio-astronomy \ --disable-gr-trellis \ --disable-gr-video-sdl \ --enable-gr-wxgui \ --enable-pmt \ --enable-mblock \ --disable-ezdop \ --disable-gr-ezdop \ --enable-gnuradio-examples \ " ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with tx path in bbn code
DiX <[EMAIL PROTECTED]> writes: > Is there anyone using bbn 802.11 codes? > > I find the tx path cannot output anything to the usrp board. I connect > the packet_transmitter to a file sink by adding two lines in > bbn_80211b_transmit_path.py > " > self.fsink=gr.file_sink(gr.sizeof_gr_complex, "Tx.dat") > fg.connect(self.packet_transmitter, self.fsink) > " > > The file records nothing! What's the problem with the bbn 80211 > transmitter? Is there anything wrong with the message queue used in the > bbn_802b_pkt.py? We used the receiver much more. Beware that the default flags don't use the barker code (because it's so cpu intensive), and that you'll have to turn that on if you want to try to interoperate. How are you injecting packets into the transmitter? We had this set up to use a pseudointerface to get packets to/from the kernel from the 802.11 code. If you don't send it packets it won't send anything. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to implement an 802.11-like MAC protocol in GnuRadio?
Many people had implemented some prototypes of 802.11 protocol. For example, BBN (http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/gr-bbn/src/examples/) had shared the code of 802.11. However, the BBN's code seem only focus on physical layer of IEEE 802.11 (coding and modulation). We did not have a full stack working, but did inject received frames into the net80211 machinery so that we could run tcpdump on them. In NetBSD (and FreeBSD), see src/sys/net80211: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net80211/ That implements a lot of the upper half of the MAC, but not RTS/CTS. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Porting GNURadio to arm-linux platform
My quick reaction is that you are having problems from using different paths from (cross-)building and running. Try making an ARM destdir and installing everything into it in the same place you will have it when you run. Lots of programs configure in (via @prefix@ in foo.in) the prefix,and then look for them. Settting LD_LIBRARY_PATH is a gross hack and only addresses library search paths, but nothing else. So I think you need not only --prefix but also DESTDIR on the make install. disclaimer: I haven't actually done this. But I cross-build NetBSD itself all the time, and the above destdir/prefix scheme is how it works. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SMA -> N-type connectors for USRP
Also, you almost certainly do not want to put an adaptor on the SMA connector on the USRP; that will cause too much strain. Instead, use an SMA to SMA cable and put the adaptor (BNC male to SMA female) on the scope. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 802.11 BBN in SuSE
Teun <[EMAIL PROTECTED]> writes: > has anyone tried to capture live 802.11b - 1mbit packets using the 802.11BBN > source code in SuSE ? I am pretty sure we did this under some kind of Linux, and I think it was SuSE. > I'm trying to do so, but I'm encountering problems. First of all, when I run > usrp_fft or usrp_oscope I can definitely see something. At least, I see > power fluctuations due to my laptop's WLAN (old 802.11b) card. However, if I > try to run ./bbn_80211b_tx.py I get the following error: > > " > Using TX d'board A: Flex 2400 Tx MIMO B gr_fir_ccf: using SSE > spb:8 > interp: 32 > Failed to set Tx frequency to 2.4G " We didn't have any MIMO cards, so you may be simply hitting a minor bug. > I also tried to capture packets, using ./bbn_80211b_rx.py -d 8 -f 2412e6 -p > , however I can't see any packets. The barker code demod defaults to off (probably not a wise choice). Make sure it's on - I suggest reading the code and the option parsing in particular.This is all a bit rough. I definitely received 802.11 packets (1 Mb/s) under NetBSD. So while I'm sure there are things wrong, it's possible to make it work. See the tap example; that's what I ran most recently. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FreeBSD patches for gnuradio
Is the gr-radio-astronomy patch a FreeBSD fix, or generic? ppdev.c: I don't see why the include of sstream is conditional on the various pp methods. The diff seems to add code for Linux as well, but I wonder if that's an artifact of how diff chose to deal with before/after. Other than that question and nits, at first glance this looks fine, but you're probably over that pesky copyright assignment threshold... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] byteswapping problems in usrp code
gnuradio/trunk/usrp/host/lib/legacy/usrp_bytesex.h includes byteswap.h, which appears to be a Linux-specific header file. I looked briefly, and didn't see any POSIX/SUSv3 definitions of these macros. I just fixed this to build on NetBSD, which I suspect also fixes it on several other non-Linux systems. NetBSD has bswap macros, in machine/bswap.h: BSWAP(3)NetBSD Library Functions Manual BSWAP(3) NAME bswap16, bswap32, bswap64 -- byte-order swapping functions LIBRARY Standard C Library (libc, -lc) SYNOPSIS #include #include uint16_t bswap16(uint16_t); uint32_t bswap32(uint32_t); uint64_t bswap64(uint64_t); DESCRIPTION The bswap16(), bswap32(), and bswap64() functions return the value of their argument with the bytes inverted. They can be used to convert 16, 32 or 64 bits integers from little to big endian, or vice-versa. SEE ALSO byteorder(3) NetBSD 4.0_BETA2March 17, 1998NetBSD 4.0_BETA2 Berndt sent a patch to the list to look for this; it seems equally reasonable as the Linux header, neither being defined by a standard. Also, the code uses 'short int' and 'int', which is nonportable. It should be using the POSIX fixed-width types. I wonder if the use of swap is really right - this seems to be about host to USRP, but perhaps the USRP is always little endian? It definitely needs more comments if that's what's going on. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mobile Power Supply for USRP
Matt Ettus <[EMAIL PROTECTED]> writes: > Daniel O'Connor wrote: >> >> 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? :) > > Most of the daughterboards regulate the 6V down to 5V, so you really > need about 5.5 to 5.75 V to operate correctly. > > Matt I don't mean to question Matt's advice, but I'll note that we used 12-5V DC-DC converters at BBN (from a lead-acid battery, no vehicle charging while in use), and found that the 802.11 receive performance only dropped a dB or so compared to the wall wart supply. So I concluded that it hurt us, but didn't kill it, but since this is clearly on thin ice at best you really should get a 6V output converter. pgpf9SweVeNvC.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Does anybody care if we require gmake?
I'm thinking about requiring GNU make (gmake), instead of trying to work with whatever make we find. If we do require gmake, is anybody going to have any heartburn? I don't think it's that big a deal to require GNU make. There are lots of dependencies already, and it's likely that some of them already require GNU make. It's too bad to lose portability to 'reasonable make', but it seems that BSD make and GNU make have incompatible extensions and various things are hard to do staying in the subset. I would expect that any NetBSD system that has the prereqs for GNU Radio installed will already have GNU make installed, or else if the prereqs are from binary packages gmake could be installed as well. It will be important that there be no use of 'make' in the makefiles for recursion, and that we use $(MAKE) or whatever the right incantation is so that gmake is invoked, rather than 'make' which is BSD make on BSD systems, and probably some native make on Solaris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Shared Memory Problem
I have a problem with insufficent shared memory. I'm running GNU Radio from SVN, and keep getting these messages: You didn't mention what operating system you are running, but it could well be that you are hitting a limit on the number of segments rather than the total size. See the end of this page for setting shm limits to get the tests to pass: http://gnuradio.org/trac/wiki/NetBSDInstall ___ Discuss-gnuradio mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with BBN's 802.11 MAC
Dan Halperin <[EMAIL PROTECTED]> writes: > Sorry; I was unclear. Yes, if I put my laptop into 1Mbps mode then I can > see data packets. Even in 2Mbps mode (especially if I use the -p > option). I just don't expect there to _be_ any 1Mbps traffic on a modern > network. That makes sense. The environment we developed and tested this in was IBSS mode, and there multicast packets are sent at the basic rate of the IBSS. I think that's required by the specification. But I realize that I'm not normal to consider IBSS mode a normal case. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with BBN's 802.11 MAC
I think you should see real data packets at 1 Mb/s if there are any. I would expect multicast in IBSS mode to be like this. -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with BBN's 802.11 MAC
Could you explain more precisely what you are doing, and what happens? I have run the code under NetBSD with modified tap(4) driver that handles 802.11 in addition to Ethernet. I am not clear on the state of 802.11 support in the Linux tap driver. -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] loopback dropping final bits
Eric Blossom <[EMAIL PROTECTED]> writes: > On Wed, Mar 28, 2007 at 09:39:14PM -0700, Dan Halperin wrote: >> Same loopback code I emailed about earlier; this time I attached the >> complete file (modulo some cleanup). >> >> Here's my input file (in stupid x86 short ordering..): >> >>$ hexdump input.txt >>000 bbaa ddcc ffee 1100 3322 5544 7766 9988 >> >> and then after going through loopback.py and being packed back to bytes: >> >>$ hexdump output.txt >>000 bbaa ddcc ffee 1100 3322 5544 7766 8088 >> > > Regarding losing the last few symbols, try > > ... > graph.wait() > time.sleep(1) I wonder if there is data somewhere in the flowgraph that's less than the amount needed for the next block to run. Perhaps there should be some sort of drain operation, or query for this (that adds over components), so one can find out what's going on. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mblocks
"EVENNOU Frederic RD-TECH-GRE" <[EMAIL PROTECTED]> writes: > I am currently developping a cognitive radio demonstration system under > the GNU Radio Platform and I am particularly interested in the mblocks > extension proposed by the ADROIT Project. Reading the available > documentation and looking to the source code, I realized that the > extension is still a work in progress and I would like to know if > mblocks are already available as a base class for deriving my own signal > processing blocks. The code that is there is there and you're welcome to start hacking, but you'd be the first user - there aren't examples already in the tree, which is a sign that this won't (yet) be that easy. > Inspecting the mblock directory, I've noticed that > there are no .i files nor .py so the extension seems unavailable as a > Python module. Consequently, I would like to ask you some questions: > - Is the current mblock directory exploitable and bug proof? Certainly not - and probably the rest of the code isn't. I'm not sure what you're really getting at. Most of GNU Radio seems to run pretty reliably, but your using 'proof' makes me wonder about your requirements. > - May I use it as a base class for deriving my own signal processing > blocks? You may, but you will surely have to dig in and really understand what's going on, and supply some missing pieces. > - If I create an interface file for the mblock extension and if I > generate all other files (.so, .py, .o ...), will I be able to interface > my own module with Python? Yes, but be warned that this is likely considerable work. Sorry if I'm sounding like I'm just telling you that you need to read and understand all the code that's already present, and that sure you can do all of it but it's a lot of work, but that's how I see it. Contributions of code are always welcome (FSF assignment required as for all GNU projects). > For your information, this project is part of a PhD thesis at France > Telecom R&D (French telecommunications company) focusing on integrating > cognitive mechanisms into radios. > > Thank you in advance for your answer (and for the work done with this > extension, particularly attractive for cognitive applications). Perhaps Eric can give a status report on what's done and what's left to be done for m-blocks. Greg Troxel <[EMAIL PROTECTED]> pgp4FY62oJmqq.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Info regarding full duplex operation of RFX2400
"Rohit Gupta" <[EMAIL PROTECTED]> writes: > What if I use "two" GNURAdio boards at the same time, one for TX and another > for RX. However, they are now placed very close to each other(say <10cm). Do > you think this will be a good idea to achieve isolation between TX and RX > chains?? That will probably help, but really you need to do some engineering, planning your signal levels, estimating phase noise off channel, and probably characterize the equipment. You are not going to get a "yes that will work" from people that know almost nothing about what you are planning, or if you do you should take it with 7000 grains of salt. pgpPfqoNcbTH9.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Info regarding full duplex operation of RFX2400
"Rohit Gupta" <[EMAIL PROTECTED]> writes: > I have question regarding the full duplex operation of RFX2400 board. > Looking at the circuit diagram of the board, I understand that each RFX2400 > board has seperate receive AND transmit chain. Hence, if I connect one > antenna to "RX" port and another different antenna to "TX/RX" port and use > this system to make full duplex transceiver, is it possible that there > will be crosstalk between different RF components of RFX2400 board when both > transmit/receive chains are operating at the same time. IF yes, how bad is > its effect?? A fair question, and I haven't seen any measurements. Yes, you will have problems, but I'm not sure how bad. Presumably you will be intending to be on different frequencies (or more generally, have non-overlapping signals). Narrowband FM repeaters try to achieve on the order of 170 dB difference between tx power and rx sensitivity (e.g. 5 MHz offset at 445 MHz). This requires tuned cavity filters on transmit and rx paths, and also good isolation in the radio, usually with separate metal compartments and power supply isolation. So, issues will be common power supply, noise sidebands from the transmitter showing up at the receive frequency (repeaters pass tx/notch rx in the tx line, and pass rx notch tx in the rx line), and downconverter LO phase noise causing transmit components to show up in the receive passband (reciprocal mixing). All that said, I don't really have a handle on the noise sidebands in USRP/RFX2400. You certainly aren't going to be able to build a narrowband FM repeater with 50W transmit and -120 dBm receive sensitivity :-) pgpef5suXEoLn.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Good laptop for GR/USRP
It would be good to see benchmarks of the blocks that dominate receivers on various processors. I think for our 802.11 receiver the most time went to FIR filters. You didn't specify if your workload was floating point or integer; I suspect that the chip with best performance will be different. 3) Memory probably isn't a huge concern. We will probably be getting 1GB of ram. Maybe that's enough, but I wouldn't buy a machine with < 2 GB for any purpose today. You didn't mention the USRP bandwidth you want, but I'll guess that you'll be maxed out at 32 MB/s. Intel EHCI chips work well, and I have the impression that many other implementations do not. Perhaps obvious, but hardware reliability and having the devices supported by the OS you are going to run, without binary drivers, is also in general important. I am using a Thinkpad T60 with Core Duo T2300: cpu0: Intel Pentium M (Yonah) (686-class), 2161.46 MHz, id 0x6e8 cpu0: "Genuine Intel(R) CPU T2600 @ 2.16GHz" cpu0: I-cache 32 KB 64B/line 8-way, D-cache 32 KB 64B/line 8-way cpu0: L2 cache 2 MB 64B/line 8-way cpu0: using thermal monitor 1 There is L2 cache, but I don't have that handy. Now you can get T60s with Core 2 Duos. With the 100 GB disk that came with the T60, I get 39 MB/s raw read rate (at the beginning), and I think write is similar. I have more RAM than free disk space so can't benchmark writing reasonably. An external disk may well be faster, but typically you'd use USB and I'm not sure the controller can deal with that at the same time as the USRP and max them both out. You might consider some sort of network-attached storage - I'm unclear on your portability/cost requirements. What data rate do you need to sustain? Eric has an X60 that he's been happy with. If you're going to run GNU Radio semi-constantly on laptops, I bet you're going to have grief from too much heat. If so, get a 3-yr warranty (e.g. Thinkpad) and install them with risers for good airflow. The T60 is a lot better in this regard than the T30 I had before, which ran very hot, and in which the video card failed after 3.5 years (of very hard and frequent use, so I was happy overall). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Commit-gnuradio] r4735 - gnuradio/trunk/usrp/doc
+This is preliminary design document on the organization of the host +component of the USRP inband signaling implementation over USB. + +Assumptions: we'll have a single usrp_usb_daemon, implemented as an +mblock, that will provide the high-level message based interface to +the USRP. The daemon will handle all resource allocation, muxing and +demuxing for the control and status messages from multiple clients. It would be nice if the design for in-band signaling treated USB as the (current) special case, and was done with GigE etc. in mind. I didn't see anything that jumped out from this viewpoint, but earlier is better to avoid trouble. Do you expect that allocation of capacity is anything more than internal control within the usrp daemon? That conjures up isochronous bus transactions and OS-level reservations, but I don't think you mean that. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to generate control signals between block?
Once such a packet is found then the flowgraph has a message sink
and puts this half-baked packet in this queue, together with
possibly another message of a different TYPE (control message) with
some parameters required in the second flow (such as initial phase
estimate, etc).
Have you looked at the m-block design (discussion in list archives)
and work in progress? I realize it's not ready yet, and that you
might want to do something before it is, but it seems like this is an
ad hoc version of the more general scheme.
--
Greg Troxel <[EMAIL PROTECTED]>
pgpqRu90PUKZ5.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 gri_fftw
John Clark <[EMAIL PROTECTED]> writes: > Greg Troxel schrieb: >> You left out a lot, like what operating system you are using. But >> I'll guess that gr_vmcircbuf_createfilemapping is trying to mmap a >> file in tmp to get shared memory, and it needs to be writable. >> Perhaps using mfs or tmpfs, or some other kind of memory filesystem >> for /tmp is in order. > > I'm using Linux... and whatever 'gr-vmcircbuf_createfilemapping' is, > is buried deep in the gnuradio > sources. > > In this case it looks like there's a presumption about the 'user' and > having a directory associated with > that user, where 'preferences', etc. can be read/written, rather than > using say, /tmp or similar 'well known' > writeable location. So far people seem to run GNU Radio as users, so there are probably hidden assumptions about the environment that need to be tracked down and fixed. We were able to make it run as a daemon to receive 802.11 and inject the packets via a tap interface (on NetBSD). But, we weren't trying to do this on a ro filesystem. truss is probably useful to find the failing system call. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
I am able to build svn head on NetBSD, including mblock. It seems to be using the new .la references for pmt and omnithread. (I have up-to-date auto* and swig and gcc 4.1.2.) Making all in src gmake[1]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/mblock/src' Making all in lib gmake[2]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/mblock/src/lib' /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_connection.lo -MD -MP -MF .deps/mb_connection.Tpo -c -o mb_connection.lo mb_connection.cc mkdir .libs g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_connection.lo -MD -MP -MF .deps/mb_connection.Tpo -c mb_connection.cc -fPIC -DPIC -o .libs/mb_connection.o mv -f .deps/mb_connection.Tpo .deps/mb_connection.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_endpoint.lo -MD -MP -MF .deps/mb_endpoint.Tpo -c -o mb_endpoint.lo mb_endpoint.cc g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_endpoint.lo -MD -MP -MF .deps/mb_endpoint.Tpo -c mb_endpoint.cc -fPIC -DPIC -o .libs/mb_endpoint.o mv -f .deps/mb_endpoint.Tpo .deps/mb_endpoint.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_exception.lo -MD -MP -MF .deps/mb_exception.Tpo -c -o mb_exception.lo mb_exception.cc g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_exception.lo -MD -MP -MF .deps/mb_exception.Tpo -c mb_exception.cc -fPIC -DPIC -o .libs/mb_exception.o mv -f .deps/mb_exception.Tpo .deps/mb_exception.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_mblock.lo -MD -MP -MF .deps/mb_mblock.Tpo -c -o mb_mblock.lo mb_mblock.cc g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_mblock.lo -MD -MP -MF .deps/mb_mblock.Tpo -c mb_mblock.cc -fPIC -DPIC -o .libs/mb_mblock.o mv -f .deps/mb_mblock.Tpo .deps/mb_mblock.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_mblock_impl.lo -MD -MP -MF .deps/mb_mblock_impl.Tpo -c -o mb_mblock_impl.lo mb_mblock_impl.cc g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_mblock_impl.lo -MD -MP -MF .deps/mb_mblock_impl.Tpo -c mb_mblock_impl.cc -fPIC -DPIC -o .libs/mb_mblock_impl.o mv -f .deps/mb_mblock_impl.Tpo .deps/mb_mblock_impl.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_message.lo -MD -MP -MF .deps/mb_message.Tpo -c -o mb_message.lo mb_message.cc g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_message.lo -MD -MP -MF .deps/mb_message.Tpo -c mb_message.cc -fPIC -DPIC -o .libs/mb_message.o mv -f .deps/mb_message.Tpo .deps/mb_message.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_ms
Re: [Discuss-gnuradio] problem with gri_fftw
You left out a lot, like what operating system you are using. But
I'll guess that gr_vmcircbuf_createfilemapping is trying to mmap a
file in tmp to get shared memory, and it needs to be writable.
Perhaps using mfs or tmpfs, or some other kind of memory filesystem
for /tmp is in order.
It may be that the diagnostics are not quite right. Try
ktrace/truss/etc.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling
Eric Blossom <[EMAIL PROTECTED]> writes: > Sure. It's a common operation now. We often run an fft in one > process and some kind of transmitter in another. Somebody's got to > handle the dumuxing of command replies. Using your UDP example, we'd > have the source port of the request to route the reply. That still > leaves the flags such as Overrun, Underrun, etc., which I was thinking > were only going to get reported once, and then cleared. (I didn't see > a good reason for forcing the host to explicitly clear the flag.) I envision some number of data streams to/from the USRP, each with it's own destination on the host. They then could each have over/underrun flags. If it's mainly about tx vs rx, or separate data streams, then that's something that could be muxed on udp port. This likely requires a lot more thought. > On Tue, Feb 27, 2007 at 11:28:26AM -0500, Greg Troxel wrote: > >> It may make sense to define a TCP or SCTP method, but then again it >> may not - this is perhipheral attachment. > > I'd hate to try to stuff either of those in an inexpensive FPGA. Of > course if somebody wanted those, they could stick some kind of single > board computer next to the USRPng and have it run TCP or SCTP or > whatever. Sure - I was thinking the same thing. The requirements document probably should say "local bus attachment". ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling
Eric Blossom <[EMAIL PROTECTED]> writes: > On Tue, Feb 27, 2007 at 07:49:02AM -0500, Greg Troxel wrote: >> I'm thinking layer 2 with a unique Ethernet packet type (probably use >> some abandoned packet type). That said, there's nothing stopping us >> from doing UDP, except the additional bandwidth. I don't see any need >> to do TCP. >> >> I think that it should be possible for an unprivileged user (on most >> Free systems) to interact with a USRP over GigE. Actually this raises >> the issue of authorization and confidentiality/integrity of the data, >> probably taken care of by a dedicated ethernet port. > > Under GNU/Linux they may need to be holding CAP_NET_RAW, since I > think the way to get the raw ethernet frames is with libpcap and/or > opening a raw socket using socket(PF_PACKET, SOCK_RAW, ...) > > Any idea how we would get this done under *BSD? Two ways: use bpf. This requires r/w access to /dev/bpf, but that also enables reading and writing other traffic. Presumably CAP_NET_RAW on Linux does too, and that's overly broad. write a protocol family driver for the USRP ethertype (hard) To me, this all argues for IP/UDP (at the cost of 28 bytes) being the standard approach, with raw being an optimization if needed. It handles the privilege issues, and gives you multiplexing hooks (which we may not usually need). > I'm hoping on suitable machines to be able to run near wire-speed, so > that also argues for a dedicated ethernet port. Sure, but speed should be an orthogonal design issue from security and multiplexing. > Also, absent some driver hacking to mux and demux commands and > responses, we may need a user space process to handle that stuff. In > that case, only that processes would need access to the magic socket, > and the rest of the user code would use some kind of IPC to talk to > that one. OK, but that's likely to be somewhat slower. But I don't understand the mux/demux need, beyond connecting a USRP to a user process. Do you envision two programs each accessing some part of the resources on a single GigE connected USRPng? > Pause frames provide flow control. According to folks at Vanu > (who use Gigabit ethernet to implement their basestations), that's > been sufficient, assuming any switches along the way aren't brain > damaged. Locally, sure one can enforce that by declaring them broken and replacing them. > If somebody wanted to ship samples a long way reliably, then some > higher-level protocol is probably in order. It may make sense to define a TCP or SCTP method, but then again it may not - this is perhipheral attachment. pgpb5PPvkikQ3.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling
I'm thinking layer 2 with a unique Ethernet packet type (probably use some abandoned packet type). That said, there's nothing stopping us from doing UDP, except the additional bandwidth. I don't see any need to do TCP. I think that it should be possible for an unprivileged user (on most Free systems) to interact with a USRP over GigE. Actually this raises the issue of authorization and confidentiality/integrity of the data, probably taken care of by a dedicated ethernet port. USB is said to be reliable. Presumably you mean to have that same property via pause frames. -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc2 available for testing
Eric Blossom <[EMAIL PROTECTED]> writes: > On Mon, Feb 26, 2007 at 09:13:15PM -0500, Greg Troxel wrote: >> >> I wonder how hard it could be to have each component define an >> autoconf variable >> >> LIBS_GR_FOO >> >> to be either >> >> $(top_srcdir)/gr-foo/src/lib/libgnuradio-foo.la >> >> or >> >> $(libdir)/libgnuradio-foo.la >> >> depending on whether the component is enabled or not. >> This would, I think, safely link against the intended library. >> >> (I can hear you saying to create a trial fix branch with this :-) > > Wow, that sounds like a great idea! ;) > > Is it your assumption that we'd always build using the build-tree > includes? I didn't think about that much, but the above suggestion results in using the build-tree includes. Arguably the installed includes for just those components should be used, but CPPFLAGS isn't powerful enough to do that. In practice it doesn't matter, since pkgsrc and hopefully other packaging system using this technique would have all packages consistently built from the same release tarball. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc2 available for testing
I wonder how hard it could be to have each component define an autoconf variable LIBS_GR_FOO to be either $(top_srcdir)/gr-foo/src/lib/libgnuradio-foo.la or $(libdir)/libgnuradio-foo.la depending on whether the component is enabled or not. This would, I think, safely link against the intended library. (I can hear you saying to create a trial fix branch with this :-) -- Greg Troxel <[EMAIL PROTECTED]> pgpxlhalU74qg.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc2 available for testing
Do the packages install the .la file? Perhaps some sort of conditional that uses in-tree for configured component and in-$libdir for unconfigured components would be the right thing. -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] libtool/linker/dynamic loader stuff
That sounds good to me, but if we're talking a major change, I'd like to throw out something somewhere between desire and requirement: If a component A is enabled, but a GNU Radio component B that is a dependency for A is not enabled (by configure), then build and make check both use the installed version of B. This property is needed in order to be able to build separate packages for separate parts of GNU Radio, or at least to do so reasonably. Berndt: can you comment on whether this works ok now? If so, can you explain how/why? I'll also comment that some systems, including the BSDs, use -R (or -rpath) to encode the search path for dependencies in executables and libraries. This is different from the Linux use of a global path, and the resulting apparently not infrequent use of LD_LIBRARY_PATH. It is also different from the Mac OS X way of encoding full paths for dependencies. I think libtool deals with this correctly. It is likely that if all works ok on NetBSD that it will also be ok on OpenBSD and FreeBSD. I think GNU Radio largely has the desired properties already, but not quite. I believe that having a linker search path that looks in the build tree and then the installed system at build time, and that then avoids the build tree when final installation happens is sufficient. It may be that there is a -lfoo instead of libfoo.la in a Makefile now. Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] compile failure of svn head with slightly old install
Eric Blossom <[EMAIL PROTECTED]> writes: > The build tree should be linking against the build tree > (non-installed) libs. I agree, and pretty clearly it wasn't. > I understand your goal, but that's not how we're currently doing it. > If you've got a suggestion (and a patch) to handle this robustly both > ways, I'm willing to entertain it. Entirely reasonable. > What I want to be sure that we can do is to run make check against the > non-installed libraries prior to installation. > > Is NetBSD using a vanilla version of libtool, or a modified version? pkgsrc has a slightly modified version, but it seems to be only patches for various platforms that haven't been merged upstream for various reasons. I'm aware of no intent to behave oddly on purpose. Jonathan Corgan wrote: On my main development system (Linux Ubuntu 6.10), I normally do a 'make uninstall' to clean out the system directories of related libraries, .py files, .h files, etc. Then I do a 'make distclean' inside the tree, to remove all the old cruft. Only then do I do the usual ./bootstrap, ./configure, etc. I did make uninstall, clean, make and it built. But I'd say it's a bug if you have to uninstall first. I can't trivially reproduce this first, but it seems to be mblock's use of pmt that's troublesome. This could be just the only user of functions that changed signature, though. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] compile failure of svn head with slightly old install
I updated and tried to build the head of svn recently after not having done so for several weeks. The block code failed to build, complaining about several pmt_foo functions not being found. I did a 'make -k install' from top level, and then it built fine. So it seems that the build is linking against installed libs rather than in-tree libs. I'm of two minds here, becaues I think it's very important that we be able to build components by themselves against installed libraries. So, probabaly the build should use -L for the build tree and then also the installed path, in that order. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FM Transmitter?
"marcus estes" <[EMAIL PROTECTED]> writes: > Hello, > > I am a volunteer with a local non-profit based in Portland, OR that is > preparing an license application for a full-power station as soon as a > mysterious 5 day filing window is opened by the FCC later this year. > > We are currently investigating costs for the broadcast equipment. > Could a 5,000 - 10,000 watt transmitter be built using GNU Radio and > the appropriate hardware? Theoretically, yes, but you'd still need the power amplifier and the studio mixing equipment. > Would there be significant cost savings involved? No, it would probably cost more and be harder operationally. And you'll very likely need FCC type-approved equipment. > If the code has been developed (this looks interesting: > http://kd5zaa.cafe150.com/sdr/), is this platform stable enough to > run a real radio station? Probably not. I haven't heard of anyone achieving anything like 30s/year downtime with GNU Radio. The main strengths of software radio are the ability to do new things by changing software, and to vary behavior (modulation, rates) adaptively. Neither is important for your application, which is to produce a signal specified by the FCC and unlikely to change. I would suggest that you find someone who understands broadcast radio engineering. pgptljPOqkirI.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD and sysv shm
Eric Blossom <[EMAIL PROTECTED]> writes: > On Wed, Jan 31, 2007 at 03:01:51PM -0500, Greg Troxel wrote: >> I looked into this more, and conclude that there is no evidence for >> bugs in NetBSD shm support, just perhaps resource defaults that aren't >> big enough. >> >> The reason so many attachments are needed is that 64 objects are >> created, and each has 4 shmat calls. This seems excessive, but I >> don't know if the test is intended to consume that many resources. > > 64 is possibly a little high, but the idea was to have the failure at > make check time rather than downstream at runtime. At runtime there > is a buffer object allocated for each output of each block. That makes sense; it indeed fails at make check time because 256 attachments is higher than the defaults, which are 128 segments total and 128 attachments per process (if I follow correctly). My impression of the culture of sysv shm use has been that there are fairly few shm segments, and that NetBSD's resource limits are reasonable. If that's a wrong impression I can try to change them, but my impression is still that GNU Radio is a particularly heavy user (which is fine, but not necessarily a reason to change the defaults). sysv shm is particularly troublesome because buggy code can leak segments. > There are 4 attaches to create each buffer. Two of them are for guard > regions on either side of the buffer. Those regions are setup > READ_ONLY, and are to trap write accesses off the beginning or end of > the bufer. If munmap is available, we could modify the code to > create holes that had no access. The other two are the mappings that > implement the two continguous copies of the circular buffer. This is the sysv_shm case and the mmap case works fine, so there's no real problem. I was just curious why this failed because I thought NetBSD had working sysv shm support. Evidently it does, with lower limits than the test needs, or at least the test finds no problems. Interestingly, the 'junk pointer in free' message that I saw earlier no longer appears. pgp98UQOO9sn6.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD and sysv shm
I looked into this more, and conclude that there is no evidence for bugs in NetBSD shm support, just perhaps resource defaults that aren't big enough. The reason so many attachments are needed is that 64 objects are created, and each has 4 shmat calls. This seems excessive, but I don't know if the test is intended to consume that many resources. Eric and I have recently beat on the few known NetBSD nits; now make check passes on NetBSD 4.0_BETA2 with up-to-date packages from pkgsrc (including jack, port-audio, SDL, py-ephem so most components are built). -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NetBSD and sysv shm
I fixed a memory leak in an error case in the sysv shm vmcircbuf tests. Now the test leaves no shm turds in either success or error cases. I found that I had to set the number of shm segment names and segments per process to what seem unreasonably high values. This is documented in http://gnuradio.utah.edu/trac/wiki/NetBSDInstall and I'll raise it with NetBSD folks as it seems there is something wrong. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make check fails on NetBSD
Following up to Jonathan's request for tickets, please see 85: memory test fails 133: build failure without "python" in path 134: build failure without exp10 -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FYI: svn-current build problem
The current subversion build is broken on NetBSD, and probably on other systems that don't support the non-standard "exp10" function (posix defines exp and log and log10, but not exp10). config.h is trying to provide exp10 when it doesn't exist by defining an inline procedure using pow. This is fine, but config.h is not protected against multiple inclusion and there's also not a test for multiple inclusion. The file Berndt refers to apparently includes config.h twice. I hand-edited in an #ifndef/#define/#endif and then things built. I couldn't even figure out how config.h gets included once. The offending file is gnuradio-core/src/lib/swig/gnuradio_swig_py_io.cc With that change, and having a 'python' symlink (ticket #133), the build completes. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] warning about greylisting
In case anyone's having mail trouble, note that the gnu.org mx is acting odd, which doesn't give me a warm fuzzy that it won't do further odd things. Greylisting is one thing, and I can certainly understand that, but I don't know how they think my NetBSD box running postfix is windows. I haven't noticed this before; usually my posts to the list go through promptly. -Queue ID- --Size-- Arrival Time -Sender/Recipient--- A64B75299 60851 Mon Jan 29 12:06:32 [EMAIL PROTECTED] (host mx20.gnu.org[199.232.41.8] said: 451-You seem to be a Windows machine. Our condolences. You're greylisted for 20 451 minutes. Come back later. (in reply to RCPT TO command)) discuss-gnuradio@gnu.org 311265297 1637 Mon Jan 29 12:01:11 [EMAIL PROTECTED] (host mx20.gnu.org[199.232.41.8] said: 451-You seem to be a Windows machine. Our condolences. You're greylisted for 20 451 minutes. Come back later. (in reply to RCPT TO command)) discuss-gnuradio@gnu.org -- 61 Kbytes in 2 Requests. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] more gmsk issues
"Brett L. Trotter" <[EMAIL PROTECTED]> writes: > I saw the fragments not making it, but by didn't see anything of note, I > meant I didn't see anything that caused that condition. You really should have explained what you found; in debugging it's critical to share all the facts. >> Could you set the MTU to avoid fragmentation, perhaps to 576 (ip >> bytes)? Or try scping a file, which will/should adapt MSS to MTU > > scp was the first thing we tried and that locks up similarly- even SSH > locks up after a certain amount of traffic (catting /dev/urandom through > strings to generate traffic). That's why I started investigating UDP > mechanisms thinking perhaps TCP was bad over the USRP/gmsk. So what is "certain amount"? How does that vary? Can you start a new transfer without restarting GNU Radio? What packet sizes are observed with scp? Is there fragmentation? >> The last 2nd fragment (meaning offset 480) is id 32558, so it seems >> that your system in getting in a state where the second fragment is >> always dropped. Is there some queue which is always full or nearly >> full and therefore when 2 back-to-back frames get sent the second is >> always dropped? Using TCP may avoid this problem, since it will back >> off more aggressively. >> >> It may be that you are finding bugs in your system's fragment >> reassembly code. > > I hope not, there'd be no way for me to fix it. This is on Fedora Core 6 > x86_64 running on an FX-60 dual core 2.6 GHz w/ 2GB ram. So far, it looks to me like the system gets in a mode where it drops 2nd fragments, and that's the root cause. But you'll have to be far more methodical and report far more details if this is to be figured out. I think you really should set MTU (and perhaps TCP MSS or packet size in FSP) to avoid IP fragmentation. IP fragmentation is generally recognized as a bad idea and something to be avoided. pgpdVdevQwkSe.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] more gmsk issues
You are experiencing IP fragmentation. This could explain why ping still works. Starting at id 32559, I can see both fragments in the .1 trace, but only the first in the .2 trace. Look at 13:44:47.258668 in the second trace, and note that offset 0 is present but not offset 480. In the first trace at 13:44:46.815874 both fragments are there. Is your transport protocol congestion friendly, meaning will it back off when it doesn't get acks? It seems to go down to 1 packet/second. Could you set the MTU to avoid fragmentation, perhaps to 576 (ip bytes)? Or try scping a file, which will/should adapt MSS to MTU The last 2nd fragment (meaning offset 480) is id 32558, so it seems that your system in getting in a state where the second fragment is always dropped. Is there some queue which is always full or nearly full and therefore when 2 back-to-back frames get sent the second is always dropped? Using TCP may avoid this problem, since it will back off more aggressively. It may be that you are finding bugs in your system's fragment reassembly code. Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] more gmsk issues
So the bottom line question is why in the heck would a file transfer over a
stateless protocol get frozen after a certain number of bytes when it
appears I can ping with large payloads indefinitely?
For the record, anything terribly deep in python or networking code is
beyond me- so aside from simple settings tweaks and protocol/application
selection to garner stability, I'm probably out of my league.
No one can tell without looking at the data.
You really need to look at both sides with tcpdump. Packets that are
sent should, at least probably, arrive. It may be that there is some
bit pattern that results in them always not arriving, and you can
debug that at the MAC/PHY layer without understanding why the upper
layer is sending that pattern.
--
Greg Troxel <[EMAIL PROTECTED]>
___
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
Brett Trotter <[EMAIL PROTECTED]> writes: > Replying to myself, it seems that if I do an ssh and cat a bunch of data > from /dev/urandom through strings, eventually, the tunnel cant keep up and > data stops streaming. Funny enough though, if I hit a key, it still sends > data. It seems as if the ssh session got out of sync. Another ssh session > running simultaneously, but not actively communicating, remains happy once > the other dies. I suggest taking tcpdumps on both sides on the tunnel device, and use -w file -s1500 to save them. When looking with -r file -vv you should be warned if there are checksum failures. Also, look at network statistics. On BSD I'd look at "netstat -s -p ip" and "netstat -s -p tcp" to look for packets discarded due to checkcum failure; I don't know how to get at the corresponding counters on Linux. Not with GNU Radio, but I have seen ssh sessions have trouble due to data corruption. I never figured out the source, but packets had ok tcp checksums but failed the CRC, so ssh closed the connection. pgpjhoaEK17IN.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG compilation speedup!
Eric Blossom <[EMAIL PROTECTED]> writes: > I've just checked code into the trunk that speeds up compilation of > the swig generated code, as well as reducing the number of > dependencies for each piece. I did a make clean, updated, and then rebuilt (autogen, configure, make) on NetBSD/i386 4.99.1. It built without errors, and the "stabs" warnings I reported earlier are gone, probably because the number of labels is down below 16 bits or something like that. I noticed 330 MB working set on one of the cc1plus processes, but I remember that I had to up a build machine from 512 to 768 to avoid pain. make check also succeeded (after I deleted the pkgsrc packages; apparently that version of the libs was getting picked up by the gr-usrp tests). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with just checked out and recompiled gnuradio
I probably didn't rebuild all since swig upgrade to 1.3.31. I suppose the Makefile.am's need to have a dependency on the swig executable :-) (I know, ENOPATCH...) I got a different error, so I did make distclean and a full rebuild. Now I get this, which I'll look into when I get a chance. gdt 199 /usr/adroit/lib/python2.4/site-packages/gnuradio > python Python 2.4.3 (#1, Jul 11 2006, 02:04:00) [GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd3 Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import _audio_oss Traceback (most recent call last): File "", line 1, in ? ImportError: /usr/adroit/lib/python2.4/site-packages/gnuradio/_audio_oss.so: Undefined PLT symbol "_ZN14gr_basic_block11basic_blockEv" (symnum = 81) >>> -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with just checked out and recompiled gnuradio
I also just rebuilt, and got a different error. This is on NetBSD 4.99.5, i386, swig 1.3.31, gcc 4.1.2. Traceback (most recent call last): File "./dial_tone.py", line 55, in ? my_graph().run() File "./dial_tone.py", line 49, in __init__ self.connect (src0, (dst, 0)) File "/usr/adroit/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py", line 115, in connect self._connect (points[i-1], points[i]) File "/usr/adroit/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py", line 120, in _connect self._connect_prim (s, d) File "/usr/adroit/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py", line 126, in _connect_prim self._check_valid_dst_port (dst_endpoint) File "/usr/adroit/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py", line 225, in _check_valid_dst_port self._check_port (dst_endpoint.block.input_signature(), dst_endpoint.port) File "/usr/adroit/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py", line 230, in _check_port if signature.max_streams () == -1: # infinite AttributeError: 'PySwigObject' object has no attribute 'max_streams' swig/python detected a memory leak of type 'gr_io_signature_sptr *', no destructor found. python in free(): warning: modified (chunk-) pointer. -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] VT receives NSF grant for SDR security
This was recently pointed out to me: http://www.vtnews.vt.edu/story.php?relyear=2006&itemno=660 I'd be curious if someone from the VT team would like to comment on the ways SDR code is different from protocol code in terms of vulnerabilities. I can certainly see the ability to jam at lower layers. Or is this work like TCPA in enabling some third party to prevent SDR hardware to run unauthorize code? If so, that probably won't end up in GNU Radio :-) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 802.11 and Bluetooth
If you have some 1 or 2 Mbps 802.11 devices to use, the BBN guys have done work on receiving those (search the list, it's been addressed a number of times in the past). Yes, and also note that normally an AP will send beacons at 1 Mbps even if it is a b/g AP. Comments are welcome on README.organization in the source about where the various blocks needed for 802.11 demod should go. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [EMAIL PROTECTED] [Commit-gnuradio] r4051 - gnuradio/trunk
For those of you that don't read the commit logs: --- Begin Message --- Author: gdt Date: 2006-12-04 11:19:59 -0700 (Mon, 04 Dec 2006) New Revision: 4051 Added: gnuradio/trunk/README.organization Log: Describe issues surrounding integrating BBN's 802.11 code. Added: gnuradio/trunk/README.organization === --- gnuradio/trunk/README.organization (rev 0) +++ gnuradio/trunk/README.organization 2006-12-04 18:19:59 UTC (rev 4051) @@ -0,0 +1,34 @@ +[This file is currently not baked and does not claim to represent +consensus.] + +This file describes the current organization of the GNU Radio source +tree. It is intended to be both descriptive and normative. + +The big issues are: + +1) Should we separate by "code needed to implement protocol/modulation +foo", or related blocks. to (that are therefore not so likely to be +used together). + +2) How do m-blocks impact organization? If m-blocks are in a separate +module, which seems reasonable, then do we have most modules depend on +m-blocks rather than just core, or do we have two versions of blocks - +the classic continuous block and the m-block wrapped block? If +m-blocks become the main path, what will be less awkward? + +3) Because some (ADROIT at BBN) have proposed to implement MACs in +click instead of GNU Radio, should we have a clean separation of +MAC/PHY within GNU Radio, to facilitate using MACs implemented in +various places? + + +The immediate question is how to integrate the 802.11 implementation +done by BBN, available at: + + http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/gr-bbn/ + +This contains blocks at various places in the stack, and gdt believs +that putting them in an 802.11 module will lead to less reuse and less +of a tendency to generalize. + +[need pointers to existing documentation of big picture and what's where] ___ Commit-gnuradio mailing list Commit-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/commit-gnuradio --- End Message --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
Thanks, i'll try to look into this.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the following message: usb_control_msg failed: error sending control message: Input/output error I haven't tracked this down, but I'd be interested in fixing it. I suspect it's either something missing in NetBSD or some OS-dependent code that isn't properly abstracted. I think it might be coming from libusb, but I really don't know - the error message is a bit lame. If you can figure out the call chain that results in the error (perhaps with ktrace on the simplest program that provokes it), that would be helpful. BTW if you run -current instead of 3.1, the USRP should do 16 MB/s each way instead of 4 MB/s that you probably get on 3.1. The improvements were committed sometime this summer. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb_nblock and fusb_block_size
fusb_block_size is the size in bytes of the maximum transfer that we will ask the kernel to make to/from user-space. fusb_nblocks is the maximum number of transfers (of maximum size fusb_block_size) that we can have in flight at any given time. I think this is Linux-specific. The NetSBD USB implementation takes the numbers and pushes them into the kernel where I think there is similar treatment (total size of read-ahead buffer, and size of IO request made to USB subsystem). We'll need to come up with a clean OS/HW independent way of dealing with block sizes and controlling latency, along with enabling code to end up at the lowest latency mode that works without hand tuning. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scanning/Detecting Wifi
This code is a bit rough and not yet integrated, but you should be able to get it to run: cvs -d [EMAIL PROTECTED]:/cvs/adroitgrdevel co adroitgrdevel look in gr-bbn/src/bbn, which is quite misnamed but has 802.11 demod for the 1 Mb/s rate. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grc_gr_wxgui.m4 fix
patch applied, thanks. -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
