[Discuss-gnuradio] OpenMP accelerator used with GNU radio
All- I'm looking for advanced developers who are interested in taking our OpenMP accelerator and creating a demo GNU radio application. The accelerator is a 2.5 Teraflop (32-core) PCIe card with a 1 GBe port and is programmed via OpenMP. The objectives are twofold: -fast response / low latency: C/C++ critical response code sections are marked by OpenMP pragmas and run on the card; data doesn't reach host sw -acceleration: designated code sections are marked by OpenMP pragmas and accelerated on the card (data has already reached host sw) The latter category would not provide performance advantage over a GPU board, unless multiple blocks can be enclosed with a pragma section and run together, and or multiple sections run concurrently (main idea being to limit frequency and increase size of PCIe bus data transfers). From an Ettus hardware standpoint, the card would look like an Ethernet pass-thru for data, so UHD / standard drivers would still be used. Yes I have heard there is OpenMP support for Python, but our source code parser doesn't not handle Python yet. The card is half-size, single-width, 54 W. I'm open for questions on this. Thanks. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio is crap and GSoc
Martin- On Tue, Feb 14, 2012 at 09:11:19AM -0500, Clark Pope wrote: Without a monetization strategy I don't see how the gnu radio project gets much past its current state. The problem is the functionality of a prototyper or student is implemented in about 20% of the effort for a full application. The documentation, testing, deployment, and maintenance of a real application needs a lot more work and that work is not educational or enjoyable. So without something like an app store where developers can get reimbursed for that other 80% the applications will stay stuck at the cool demo stage. First, cool demo stage is already a pretty good stage. Second, I'd like to point out a very successful OSS project not unlike GNU Radio the USRP: the Arduino. By itself, it's useless--it's a hardware/software development tool. Sounds familiar? If you read sites like hackaday.com, the Arduino comes up *all the time* with posts like Look what X did with an Arduino. On this specific site, GNU Radio comes up 3 times, the newest article being from February 2009. Some coverage of cool hacks using GNU Radio certainly wouldn't hurt the project. All understood. Demos that highlight GNU Radio's tremendous progress are crucial to its long-term success. But nevertheless Clark makes a crucial point. GNU Radio is owned by National Instruments and I might guess their sales guys are not too happy with this thread. They can't sell cool demos. Progress must be made to create revenue-producing applications. Like Clark says, most of that work is not fun, and it eats a lot of time and effort, but in the real business world, there isn't a choice. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio is crap and GSoc
Ed-
On 2/15/12 11:31 AM, Jeff Brower wrote:
GNU Radio is owned by National Instruments .
!
You are confusing GnuRadio with Ettus Research.
GnuRadio is an open source SDR framework.
Ettus is the manufacturer of the USRP series of hardware
and the UHD driver libraries to access it.
Ok. I should have said is owned by with substantially depends on...
-Jeff
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Marcus- Alexander is asking excellent questions and I'm surprised at the tepid response -- he's got like 4 replies so far? He's the prototype GNU radio user who needs to maintain his group's IP, he should be receiving how to's, not INALs. -Jeff Actually, IANAL is a perfectly-valid response. IP licensing arrangements are complicated and studded with sinkholes and minefields. I've avoided the issue (I hope!) in my proprietary stuff that uses Gnu Radio by doing two things: o minimizing the stuff that I do inside the flow-graph if I can conveniently do it outside o speaking to the flowgraph via named pipes and moving the proprietary and user-goop into non Gnu Radio compiled code. This is probably the safest thing that somebody who isn't a lawyer can do without consulting an (expensive) IPR lawyer. I agree this is a good approach with clear intent. Especially if you can show things would work the same way if the pipes connected over Ethernet to another server that did not have GNU radio installed. Maybe if GRC had some blocks for this purpose... -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Colby- How do the companies write closed-source drivers for the Linux Kernel without running into GPL2 issues? I can only recall that there is a user-land and a kernel-land driver, where the kernel-land is the only part that is open source. Is this correct? Perhaps that method could work well? You can find many opinions either way. But as you mention, the reality on the ground is that commercial outfits often distribute binary-only versions of libraries and drivers, whether the license they're under actually permits that or not. Their argument that providing driver source would disclose proprietary information about their hardware is difficult to refute. Nvidia is one example. I continue to think future legal rulings will invoke interoperability to clarify this. Numerous people want to interoperate with Linux and still maintain their sauce as secret. Building cards that insert into servers is one obvious example. A smaller group of people want to interoperate similarly with GNU radio. Yes there are no lawyers posting here, but my point is these users should be supported in some formal, encouraged way. -Jeff I thought GPLV2 was less onerous in this regard, and that case-law had established that a loadable kernel driver didn't necessarily get infected by the GPL virus. IANAL. TINLA. Etc. The last kernel driver I worked on we were planning to open-source as a way of encouraging people to buy our (very closed-source!) chips. Project fell apart before we hit market. Sigh. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Michael- Hi Alexander - I think Martin Tom covered that GNU Radio is quite capable of being programmed for the basic receiver processing. You might need to play around a bit with your DSP blocks, but otherwise I think GNU Radio's data processing is up to the task. On May 23, 2011, at 3:50 PM, Alexander Chemeris wrote: 3) Right now all our code is open-source, but we must leave an option for proprietary plugins. How can we make this possible? 4) Related to (3) - how can we make sure our protocol stack can be embedded into a closed-source application/system? IANAL and TINAL. I think, as has been said, you'll really want to consult a lawyer to figure out how to best meet your needs. GNU Radio is licensed solely under the GPLv3, which is written with the intent that -anything directly- using source or binary becomes part of a greater work and hence would also fall under this or an equivalent license (e.g., if used in a sold product). In the case of GNU Radio, that means any C++ code that links with GNU Radio's libraries, or Python script that makes use of GNU Radio's Python / SWIG files / libraries. To the best of my knowledge, because GNU Radio is not dual-licensed, neither can greater works derived from it. Ettus' UHD code is (will be?) an example of a dual license (GPL for the primary source, or some other license allowing you to do closed source for your needs when you pay to license the code from Ettus); Qt tries to do this dual-license as well -- I don't know how well they succeed, but they do try. IMHO, you have 3 primary choices for keeping your code closed source: (0) Do not use GNU Radio; use some other project that has a less restrictive license. (1) Do not distribute a product or service that uses the code: Nobody will care how you license your code so long as you / your company does not sell or distribute your product -- e.g., if you use it just in house for testing and evaluation, then you can license it however you want. However, I doubt that this is what you're looking for: why develop such a product, but not sell or distribute it? That brings us to: (2) Make sure your code does not -directly- rely on GNU Radio's headers, Python scripts, or compiled libraries: Use currently available GNU Radio blocks as much as you can (or, those written and released by others), and then create a pipe or socket connection to your specific code. Because your code does not rely -directly- on GNU Radio's codebase / libraries, it forms an independent work thus you can license it as you choose. That said, this method is certainly a nuisance and, depending what blocks are available versus what you need, it might also be impractical (never impossible :). This is where I think licensing discussions tend to go off track. Legal precedents have clearly established requirements for interoperability. In that context, the key point is not what code links to, but where it resides and what shape it takes. Linking based arguments are fuzzy and argued ad infinitum until at least one such case reaches the Supreme Court -- not likely any time soon. If code resides across a network, across a bus (i.e. on a PCIe card inside the GNU radio host server), or some other clearly non-GNU radio location then interoperability becomes the metric. It doesn't matter what header files or libraries (or whether the libraries are static or shared object, etc) were used to create an interface to the code that is physically separate -- in that case, the code is clearly out of the scope of the license. I've mentioned on the forum before the need for ways to insert proprietary code within the GNU radio framework, as have others. For example, is it possible for GNU radio users to insert code blocks into the FPGA data flow, for instance if FPGA Verilog code contained user defined stubs or simple reference examples to serve as a starting point? Could an Nvidia accelerator be used? To me, it's a matter of imagination, creativity, and persistence -- if GNU radio developers believe in the need for proprietary IP within their framework, then it can be done. So far, evidently, they don't believe. Alexander is asking excellent questions and I'm surprised at the tepid response -- he's got like 4 replies so far? He's the prototype GNU radio user who needs to maintain his group's IP, he should be receiving how to's, not INALs. -Jeff I don't know of another way to look at this issue -- maybe someone on this list is more enlightened? That said: Unless you feel strongly that your work truly needs to be proprietary, then why not just create a project on the CGRAN or your preferred area (e.g., github) make your work public -- it will benefit many others in the SDR / DSP world (and, likely, beyond). Good luck, and please do keep the list informed on your project -- it sounds quite interesting! - MLD
Re: [Discuss-gnuradio] Why Isn't GNU Radio Used More?
Martin- : : To a non GPL-philic, non-nerd, why choose GNU Radio? There is no reason: - Matlab is generally free of charge for universities - Matlab is used by the industry - Matlab is better documented and has a wider user base - Simulink has more blocks already incorporated - Matlab/Simulink has a much wider applicability outside realtime DSP Here at CEL, the majority of student's projects are done using Matlab/Simulink. In that case, what hardware are your students using with MATLAB/Simulink? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why Isn't GNU Radio Used More?
Martin- On Tue, May 10, 2011 at 09:07:38AM -0500, Jeff Brower wrote: Martin- To a non GPL-philic, non-nerd, why choose GNU Radio? There is no reason: - Matlab is generally free of charge for universities - Matlab is used by the industry - Matlab is better documented and has a wider user base - Simulink has more blocks already incorporated - Matlab/Simulink has a much wider applicability outside realtime DSP Here at CEL, the majority of student's projects are done using Matlab/Simulink. In that case, what hardware are your students using with MATLAB/Simulink? Most use USRPs, but we also have some Lyrtech SFF SDRs. If this can be generalized, then the academic situation seems good then. Matt has solved the foremost problem: get hardware into circulation and bring in some revenue. Then the question is how to gain wider academic acceptance on the software side. Since Mathworks and NI are arch rivals, I would think NI is looking at how to do this and giving Matt the assistance he needs. Maybe better Win support, as others have mentioned. Maybe adding things that leverage the hardware and the student version of Simulink isn't going to do, such as user-defined Verilog code blocks that run on the FPGA (and are easy to use from a Win GUI). -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why Isn't GNU Radio Used More?
Alexander- Well said. I would add an additional comment about Linux as a model for GNU Radio. Linux exists at least in part because of widespread developer anger with Microsoft in the 1990s. Guys like Ballmer simply couldn't think straight and failed to respect developers' time and effort. Linux solved that problem but seems to have reached limits, such as desktop applications. It's less an economic model and more a model for global cooperation and standardization in a fundamental area of software too important to be left to short-term oriented executives. What I think might translate for GNU Radio is to find ways to support more types of platforms. What about a small USRP for smart phones and tablets? Would that draw in more developers? A platform broadening might also make sense from a revenue standpoint: small open source initiatives need revenue streams to grow and be able to afford things such as extensive documentation. For GNU Radio, this means hardware. -Jeff On Mon, May 9, 2011 at 20:08, Philip Balister phi...@balister.org wrote: On 05/09/2011 11:57 AM, Michael Dickens wrote: Intellectual Property: Many people / companies view the GPL as being incompatible with IP -- and, whether true or not, this perception is certainly an issue. Â To make progress here, maybe GNU Radio could take Ettus' UHD dual-license approach, if that is still possible? Â I don't know if the FSF (the copyright owner) would allow such a change; further, even with that change, I think a separate company would need to be setup to deal with the non-GPL license. Â I think having a less-restrictive license than the GPL would encourage adoption of GNU Radio in places where IP is an issue. - MLD That's true - people don't like GPL and a good library has to do something about it. I don't see any point trying to appease the free software is anti IP crowd. They will just invent new excuses. It is our job to help these people understand how things really work. I'm also less inclined to contribute to projects using BSD style licenses since I see no benefit to me, to contribute to a project that can be used for profit by people who do not plan to share the code with their customers. I believe that a library should use LGPL instead of a clean GPL. Then all contributions to the library are shared with the community, while people are still allowed to build their black boxes. Re-licensing of GnuRadio as LGPL would be a big step towards much higher popularity. Anyway, the largest generator of dollars in the free software world is the Linux kernel, and that is GPL. So economics suggest GPL is the way to go. That's not true, Linux kernel itself doesn't generate $$$. And to say truth - Linux kernel allows you (1) to load binary proprietary drivers without open-sourcing them and (2) to use it with user-space programs without open-sourcing them. And this makes Linux kernel such an awesome thing. GnuRadio must follow this model if it wants to be considered seriously. -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why Isn't GNU Radio Used More?
Gregory- On Mon, May 9, 2011 at 2:59 PM, Andrew Lentvorski bs...@allcaps.org wrote: No embedded engineer who values his job will touch a GPL piece of code with a 10 foot pole. Â Period. and these are folks who will be out-competed in the marketplace by competitors who are more agile and less phobic. That sounds more wish than reality. For example, Apple is hardly being out-competed for being closed. Andrew makes an excellent point -- for-profit entities will avoid GPL if it means placing their code of value into the public domain. They will use GPL code when it saves time/cost and continue to find ways to mix and match with binary-only modules, physical separation across a bus or between dissimilar chips (or cores within an SoC), and other ways to box their proprietary code. Discussion about how to solve this within GNU radio is useful... could user-defined processing blocks be added that run on a GPU accelerator? Could a version of the USRP be made available that contains an OMAP or other device that would allow substantial user-defined baseband processing? Basically, some place to insert in the data flow user-defined code that has no GPL dependency. Documented reference examples showing how to do this would bring more users to GNU radio. -Jeff Over time, , whateverGPL whenever they can an [From the original article] Conversely, the DSA community seems to want to keep reinventing solutions. Every year we see demos that are slightly more polished and maybe a bit more expansive than the previous year's, but we still aren't really seeing huge leaps and bounds in the technology that I think we could and should be seeing. The obvious explanation is that there isn't actually a market in this space people build things here in order to demonstrate how smart and capable they areâ advancing the art is _hard_ and isn't strictly necessary for just showing that you know how to build yet another slightly better wisbang. Marcus D. Leech wrote: I think there's a significant community out there that learned DSP techniques inside the envelope of Matlab/Simulink, and that's what they're comfortable with.To change this, Gnu Radio has to appear in more places in academia, so that graduating engineers have already been exposed to it, and find it natural. One positive thing here is that python (esp with scipy/numpy) has been aggressively replacing matlab/octave in many areas. It seems that that this has gone slower RF DSP area, but this shouldn't be surprising because there is a larger dependency on canned DSP objects than in some other areas. Personally, I don't find the adoption curves surprising. The entry cost for GNURadio + USRP are low compared to traditional tools, but those who could afford those are mostly already comfortable with the toolset they already know. The entry costs are very high compared to pure software activities or heavily commodity activities. If someone is doing development of high level communication systems using standard ethernet $20 off the shelf 802.11 gear then the cost (in terms of time and hardware) of doing _anything_ with GNURadio are basically astronomic. (And they would still be even if the USRP were free, though less so) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Agile Solutions is Pleased to announce USRPSTAR. Yet another addition to GNURADIO
On 04/19/2011 01:10 PM, i...@agile-sdr-solutions.com wrote: Dear Matt, We honestly went through every material in search on Google but we couldn't locate a single article published successful testing for STBC/SFBC. For whatever reason, we would like to know, if you can confirm on this with your lab setup ? We have done considerable experimental work on this. And we are certain with the results we have have found. We would encourage this exploration in best interest of all from your end. Thank you. Dear Mr. Solutions, Mr. Solutions = Akash Kosgi, Lakshmamma Layout, Banaswadi, Bangalore, 560043, India. -Jeff All USRP systems can do STBC, SFBC, spatial multiplexing, etc. I've said it multiple times and pointed you to multiple sources. Steve Peters told you he and the Hydra team at UT have done it. I have seen it done. I have done it myself. Our customers have been doing it for 6 years now. The WARP boards from Rice do it in the exact same way. Millions of WiFi systems do it the same way. Page 4, section 4 of the following paper says the same thing: http://newport.eecs.uci.edu/~hyousefi/publ/lamacGC09.pdf Our experiments rely on a MANET testbed in which each test node consists of a host PC and a USRP motherboard hosting a pair of frontend RF daughter boards. Since each daughter board is attached to a single antenna, each MANET node is equipped with a pair of antennas. When transmitting, each MANET node utilizes Space-Time Block Coding (STBC) method of [23]. I don't know what more I could possibly say. No matter how many times you ask the question, the answer will always be the same. Just because *you* couldn't get it to work doesn't mean it's impossible. Matt Ettus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TI vs Freescale DSP for open-source development
Alexander- okay here are my 2 cents 2- TI actually offers all the tools you need to develop for their DSP for free, I can vouch for the C64x+ DSP since that's what I have experience using. You can download and look at the supported DSP for the free download from http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/ The biggest issue you might run into with the free software is the ability to use a JTAG, if you want to use a JTAG you have to use Code Composer period. Though I've read about people using the free demo version of Code Composer (CCS) 4.0 with a very cheap JTAG ( $150) to debug their DSP code. I think TI restricts the type of DSPs and JTAGs you can use with the free CCS I know that the JTAG I use (XDS560) is not supported. 3- TI support for open source is surprisingly decent. I've posted many questions on their support forums and TI engineers have always gotten back to me with alot of good information and continued asnwering as posted more follow up questions. 4- The learning tool has a bit of a learning curve that's for sure. I have posted a github link on the listserv yesterday which includes new custom blocks for GNU Radio using the C64x+ DSP. You might find the guide helpful in shedding some light about developing with TI tools. 6- I've been using TI software as an open source developer for almost 1.5 years now and I think they've managed to find a great balance between being a for profit company and a supplier of tools for the open source community. I don't have experience with freescale but my experience with TI has been a positive one. We are a heavy TI device user and have been for years. Al Fayez's comments are pretty much accurate. I would add a few additional comments for MSC8x5x vs. C667x; i.e. high performance multicore CPUs (the vendors are moving away from the term DSPs nowadays, hehe). My comments apply *only* to these high-end multicore devices. My two major concerns with Freescale are a) peer support and b) product roadmap. First, there simply are not enough users. For example there is a motoroladsp Yahoo Group (there are several TI DSP Yahoo groups, C6x, C5x, etc) but in the last several years activity on the mot group has slowly died off. There are still knowledgeable Mot/Freescale DSP guys on comp.dsp, but mostly in audio/acoustic related areas. Second, product roadmap. Before they were Freescale, Mot used to have a strong, competitive product portfolio in DSP. In 1998 they started a downhill slide when their CEO re-organized his own DSP guys into an internal resource matrix, essentially deciding there wasn't actually a DSP market. Obviously TI thought otherwise and became a DSP company and we all know the rest of that story. (As a side note, that CEO was Hector Ruiz, the same guy who later presided over AMD during its decline and is now subject to an SEC investigation). In 2004, Mot DSPs became Freescale and enjoyed a resurgence with Starcore based devices. Starcore technology has always looked quite promising, but in my opinion, in day-to-day execution Freescale has not been able to match TI. Now TI has out the C667x series, which leaps beyond MSC815x/MSC825x. Not to mention that TI's multicore CPUs benefit indirectly, both in terms of technical advances, and in terms of customer support, from what TI is doing in smart phones, tablets, high-performance ARM, etc. -Jeff -Original Message- From: Alexander Chemeris alexander.cheme...@gmail.com To: Gnuradio-discuss discuss-gnuradio@gnu.org Sent: Fri, Jan 28, 2011 10:24 am Subject: [Discuss-gnuradio] TI vs Freescale DSP for open-source development Hello all, We're working on an open-source WiMAX receiver/scanner and we're looking into using a high-performance DSP to process data from USRP. Right now we implement this processing in FPGA, but we want to experiment with DSPs too. I know there are skilled people here and I'm looking forward to hear their opinion. Note, that this project is not meant for starving students or occasional hobbyists. It is for high-profile hobbyists, targeted researchers and for small companies. So please refrain from comments like no way, this is too expensive for 90% of community. Though we would appreciate comments on how to make it cheaper. So, I'm looking for the community advise about pros and cons of different DSPs. Particularly I'm interested in comparing Freescale MSC815x/MSC825x [1][2][3] and TI TMS320C667x [4][5] DSPs/SoCs from the perspective of open-source development. But if you know any other good high-profile DSPs - please propose them too. So far, as I read it we have following comparison: 1) Price. It used to be that Freescale is cheaper, but right now I see that pricing for the MSC8156 starts at $192 in 10,000 unit quantities [6], while TMX320C6670CYP is priced 160.00 USD | 1ku [7]. So they're barely the same with TI slightly
Re: [Discuss-gnuradio] TI vs Freescale DSP for open-source development
Don- Hi Jeff: interesting reply. I remember when TI and MOT did exactly the opposite. TI had the 9900 processor series that was much better than anything on the market, and essentially blew it off. MOT had the 6800/68000 series, that became moderately successful. The most crippled processor of the time, the Intel, won the day. Now the TI processors thrive, MOT is in the dumper, and Intel is king of the heap. A real riot to watch history as it happens, huh? Think also of the lovely alpha chip, and the downfall of mighty DEC. sigh. Yes things look much different years after the heat of the battle. Clarity is gained in small increments. I know some of the TI execs from the early 1980s (in fact one works with me, he was Gen Mgr of Consumer Products at the time). The general conclusion is that TI guys learned a hard lesson with the 9900 and applied it well over time. They never ventured forth again without solid development tools and other supporting software. But on the other hand they took nearly 10 years to support Linux after major players started embracing it... oh well. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option
Jamie- Hi Brian, That sounds like a pretty good system. I should say right off the bat that if I am involved to make this I would want to add a clause in the open source hardware license to not allow the hardware to be used for military applications. I think it is important to state this at the start before I would get involved working on a new gnu radio board. If people can live with that requirement I am happy to do the layout work. Obtaining critical mass with a community based, open source project is difficult enough -- you can see the very few examples that are successful and still alive after a couple of years. I'm not saying you're wrong or right, but if you make the path more narrow, your chances of success -- i.e. reaching milestones on the path and getting others to follow you -- decrease. Can you show some examples of other *successful* open source / open hardware projects where the license has this clause? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] On Starving Students
To the students: Suggest that you give Matt your Professor/Advisor contact info, and also get your Prof to send a note to Matt on your behalf. Bringing your Prof into the dialog is a good idea for several reasons. For example, there might be an opportunity to set up an instructional lab or otherwise help other students, not just you. And it's always more impressive if there is a group of students asking, not just one. Team efforts are more likely to produce results. BTW, this is how we handle it at my company. Students have to explain what they're doing and why, and get a faculty member to vouch for them and their work (i.e. a faculty member who is searchable on the Univ web site). It has worked for many years with DSP boards. -Jeff Dear List, This is the GNU Radio mailing list, and its purpose is to discuss the use and development of GNU Radio. I try to refrain from talking about our business out of respect for the purpose of this list and the community. However, due to the tenor of the recent conversation, I feel that I must say a few things. GNU Radio can be and is used with _many_ different hardware devices, not just those of our company. Some of those are completely different from the USRP, some emulate the USRP, some are based on the USRP design to a greater or lesser degree, and some are complete clones of it. Some cost less, most cost more. To my knowledge none of them other than the SSRP actually give out schematics or other technical details, but that is the choice of those designers/companies. You have the freedom to use or not use any of these, or even to make your own. If you wish to make your own in a collaborative manner, I think the GNU Radio mailing list is the perfect place to find like minded people to work with, and I would encourage you to use it as such. There are a lot of intelligent people here with a lot of experience to draw upon. At Ettus Research we get daily requests from students (and people falsely claiming to be students) all over the world for free or nearly-free hardware. Most (but not all) of them are at least a bit more courteous than the outright demands we have been receiving for the last 2 months from the multiple people who go by the name Marten Christophe. If we were to accede to all of these requests/demands we would be sending out more free USRPs than paid ones. Very early on, I fell for this trick. I sent nearly-free hardware to several so-called starving students. Most of those boards were sold on eBay at a profit. The rest, to my knowledge, were never even turned on and the students disappeared. I have always found a way to get hardware to those students who actually contribute to the GNU Radio or OpenBTS projects and demonstrate competency and a willingness to collaborate. I fully intend to continue to do so. I will not send out free hardware to someone who just shows up and demands it under a fake name. If you feel that our prices are too high, then I would encourage you to make your own hardware. If you think you are a starving student now, wait until you try to sell USRPs for $450. Matt Ettus President, Ettus Research LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Details on Ettus E100?
Elvis- On Dec 14, 2010, at 11:14 PM, Matt Ettus wrote: Since the OMAP has a GPU incorporated does that mean that we could use it for processing? Is there a CUDA equivalent for this type of GPU? Doug has it pretty correct here. This is one of those areas I would call theoretically possible, but unlikely to be worth the trouble. You would need Imagination Tech and TI to get together to release an OpenCL implementation for the GPU, and even then it isn't the world's fastest. The way I look at it, you have 3 much better, easier to use options -- the ARM, the DSP, and the FPGA. If you put all those to good use and still need more power, the GPU is not likely to contribute appreciably. A quick search on the internet yields some interesting info, but at the end, you'd probably get much better results off the FPGA. Some work done by Nokia: http://www.hotchips.org/archives/hc21/1_sun/HC21.23.2.OpenCLTutorial-Epub/HC21.23.270.Pulli-OpenCL-in-Handheld-Devices.pdf The OMAP4430 seems to have support for OpenCL as mentioned in this article: http://e2e.ti.com/blogs_/b/mobile_momentum/archive/2010/02/15/omap-4-platform-ready-to-lead-the-human-device-interaction-revolution.aspx You can get a Pandaboard from DigiKey for USD$179 which has the OMAP4430 and the required GPMC interface available on the Pandaboard expansion header, to experiment with. A statement from TI from this link: http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/43845.aspx TI does not support OpenCL for the SGX530. IMG does advertises GP-GPU applications on the SGX, but TI does not license these OpenCL drivers. The best available solution would be to use the OpenGL ES 2.0 shading language (GLSL ES 1.0) to do the single precision matrix operations that you need. Rather than displaying the output results as pixels in a framebuffer, your program on the ARM can use the results. Another statement from Imagination Technologies from this link: http://www.imgtec.com/forum/forum_posts.asp?TID=194PID=2668 The SGX530 core design that's in an OMAP 3530 board is an example of one of our products. This was licenced to TI and is a design with the capability of supporting the OpenCL Embedded profile. However, it requires the correct software i.e. drivers to expose this functionality, just like drivers are required for OpenGL ES, DirectX etc. Once we have licenced a core like this we work with the customer (in this case TI) to support them in exposing the functionality that they wish to have available in their product. So if a customer wants to expose OpenCL then this work happens, but it requires time and the desire of the customer. This means that developers don't always have full access to every feature that our cores are capable of because the driver support is still being added or the customer doesn't wish to expose that feature. In summary: we advertise an ability of our core design and our customers get a core design that can do this if they choose to enable it. The developer gets a core with access to the features that our customer has exposed. So developers don't always have access to every feature of our core. Licence deals involve a certain amount of confidentiality so I can't talk about future products or support from our customers so I can't tell you when or if OpenCL will be enabled on specific platforms on this forum at this time. A future option is to use OpenMP to annotate sections of user C code that will run on the C64x+ core. We've made some preliminary mention of this on TI's e2e forum (CIM OpenMP site:ti.com). We use OpenMP style syntax, basically the same pragmas with omp replaced by sig. For compute-intensive C code, TI cores have decent SIMD capability (especially the new C66x series) and (unlike GPUs) are also good at irregular code sections. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] gnuradio land speed record?
Date: Fri, 30 Jul 2010 10:19:35 -0700 From: dhalp...@cs.washington.edu To: m...@ettus.com CC: cepop...@hotmail.com; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] gnuradio land speed record? On 07/30/2010 09:33 AM, Clark Pope wrote: I'm curious what people do with the wideband capability of the gnuradio/usrp and what is the widest bandwidth signal one can really process with available computers? What's the most anyone has recorded or processed continuously? What level of compexity was the processing? With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 MB/s recording to disk. With 4 and 6 core systems and the i7 architecture you can get more than 5X the performance of your laptop. There are a lot of applications using the full 25 MHz of RF bandwidth. You just need to pay a lot of attention to efficiency of your program and algorithms. For 'speed record' type information, you might be interested in SORA, a software radio project from Microsoft Research. They use different hardware and custom software, but the fundamentals are the same. As Matt points out, efficiency is a function of engineering. Using modern processors, 64-bit architecture, multicore, software LUTs, and a variety of other optimizations they were able to fully process 802.11g signals of 20 MHz bandwidth and sustain reception of 54 Mbps signals including Viterbi decoding, etc. I see no reason this couldn't be done with USRP(2) / GNU Radio... but looking at Microsoft's author list they had a lot of developers working pretty hard on it! There's not a ton of detail in the original paper, and what code is available is almost certainly not something you want to look at without reading the license very carefully, but here's the link to the project website: http://research.microsoft.com/en-us/projects/sora/ and the original paper: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 Dan Thanks that's a good data point! So a huge corporation with infinite resources tops out at about 20 MHz sustained processing of what I would call a real world practical signal. Their infinite resources are in fact limited by their management's mindset and inability to think clearly about the consequences of their business model, the impact of the Internet, etc. A guy like Ballmer is just a much a reason why Linux exists as is Linus himself. His rhetoric about GPL being a cancer, Linux developers are communists, etc. has provided infinite inspiration to the guys with limited resources. SORA may be a useful data point, but advise to carefully consider the source. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can GNU Radio run on TI DSP environment?
Hanks- I am new to GNU Radio. Currently I am considering to implement basic software radio and signal processing on TI DSP environment, such as TI TMS320C674x and C647x DSPs and the evaluation boards. I know GNU radio are usually running on PC environments for Linux or Window OS, but can it also run on TI DSP? If it can, how can I do it? As a starting point, look here: http://beagleboard.org/ In this case GNU radio runs on the ARM core side of an OMAP 3530 device (not on the DSP core). OMAP 3xxx devices can be found in some smart phones, for example Mot Droid and Palm Pre. Another area to look into is TI's recent announcment for a native, factory Linux running on their DSP cores, for example 6-core C6474 device. I have not heard of a GNU radio port (or any other popular open source sw, such as Asterisk) but I'm sure people are working on it. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: »Ø¸´£º [Discuss-gnuradio] Can GNU Radio run on TI DSP environment?
Hanks- For the native, factory Linux running on their DSP cores, do you mean DSP/BIOS real-time OS? No, I mean Linux. It's a big deal for TI -- they should have had a factory Linux 10 years ago, but for whatever reasons they were way late to join the crowd. -Jeff ·¢¼þÈË£º Jeff Brower jbro...@signalogic.com ÊÕ¼þÈË£º Hanks zkon...@yahoo.com.cn ³ ËÍ£º discuss-gnuradio@gnu.org ·¢ËÍÈÕÆÚ£º 2010/7/9 (ÖÜÎå) 6:41:05 ÏÂÎç Ö÷ Ì⣺ Re: [Discuss-gnuradio] Can GNU Radio run on TI DSP environment? Hanks- I am new to GNU Radio. Currently I am considering to implement basic software radio and signal processing on TI DSP environment, such as TI TMS320C674x and C647x DSPs and the evaluation boards. I know GNU radio are usually running on PC environments for Linux or Window OS, but can it also run on TI DSP? If it can, how can I do it? As a starting point, look here: http://beagleboard.org/ In this case GNU radio runs on the ARM core side of an OMAP 3530 device (not on the DSP core). OMAP 3xxx devices can be found in some smart phones, for example Mot Droid and Palm Pre. Another area to look into is TI's recent announcment for a native, factory Linux running on their DSP cores, for example 6-core C6474 device. I have not heard of a GNU radio port (or any other popular open source sw, such as Asterisk) but I'm sure people are working on it. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] find_usrps No USRP2 found.
Steve- Further to my problem trying to discover the USRP2. From a cold start (the USRP2 was left without power since my last posts) I configure the GigE port using ethtool and enable TX pause frames (this seems to be necessary magic on my PC). I then run this at the command line: while true; do clear; find_usrps; sleep 1; done and watch the output. For the first 30 seconds or so I get the device MAC address then No USRP2 found. From a real cold start this takes a little longer so I got as far as running usrp2_fft.py -f 925M and that guarantees I lose connectivity. Have removed the power and lid on the USRP2 and see U12 which is a large-ish package and gingerly touch it. It is indeed quite hot. Once the device has stopped responding even removing the power for a few minutes is not enough to make it functional so a heat-related failure of the PHY chip seems plausible. Before I go about requesting a return authorization is there any other diagnostic I can perform? Many thanks to all (especially Marcus) for your help U12 is the PHY. PHYs tend to run somewhat hot, so likely what you're seeing is Ok. But, with the top off, you could try pointing a large fan at the chip, and see what happens again from cold start. If the fan reduces the chip surface temperature to the point where you can hold your finger there (at least for 30 sec or so) and you still have the connectivity issues, then you can rule out a chip/board/heat problem. That's not saying something else hasn't gone wrong with your board, but it might help you to obtain consistent results between cold start and warm start and make it easier to debug. -Jeff Marcus D. Leech wrote: There were a batch of bad PHY chips, and I wonder if yours is one of them. U12, a DP83865 is the Gigabit PHY. On bad versions of this chip, they run *really hot*. You could *gingerly* feel yours and see if it's really uncomfortably hot. If so, you likely have a bad PHY, in which case, it should be returned. They've been having occasional trouble with this PHY chip, and they pass the checks but fail sometime later. Although I did get find_usrps working briefly (by enabling TX pause) I couldn't get any data into usrp2_fft.py. Repeating the steps I tried earlier just have it fail again. It is, however, forgetting the tx pause flag - could that be a negotiation thing? I shall whip the cover off later and do as you suggest from a cold start. If its a bad PHY then I shall make arrangements to return the USRP. Many thanks Steve ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RANT ALERT: WTF Is wrong with you people?
Marcus- Your sentiments are understandable. I know the feeling. But please allow me to give an a different perspective. I've posted for years (since 1999) 1000s of times on DSP, audio, speech, MATLAB and FPGA groups -- on voluntary basis, because I want to. I can't count the number of times I've answered totally clueless newbie posts, mostly by students or start-up wannabe's. I've developed my own methodology to minimize my time and qualify the newb (ask a couple of quick questions about their problem, see if they respond, see if they're willing to follow instructions, do some debug work, etc). Did I waste my time? Yes in many cases. But in other those newbs did good. They were persistent, followed advice, started getting results... sometimes I eventually got to see the It Works! post with thanks to all the group members who helped them -- which never fails to remind me of my own excitement so many years ago when I studied engineering in school and got my first design job. You can tell who will become the real engineers, the ones who enjoy the process, who are willing to fight the bug in hand-to-hand combat, the ones who reply at 2:00 a.m. because they're still in the lab duking it out... I like to believe that through a group / collaborative effort, they came in as newbs and then gained confidence and maybe even some validation of their career choice. Yes I know such positive results are a minority of the posts you're thinking about. And yes it takes patience and can be exasperating, but isn't that generally true of raising kids? They have to learn the hard way, and someone has to help them, before they can join the community and make their own contributions. For me overall, the good has outweighed the bad and I don't think my time has been wasted. -Jeff I've noticed a disquieting, nay, alarming, trend on this mailing list in the last year or so. Software Defined Radio has become cool, it has become the chic thing to do in graduate school, or as the foundation for the start up of a new business. Everybody wants to do it. People get on to this list, empty vessels that they are, and determine that they can become filled up. Now, when I say empty vessel, I'm talking about the poly-dimensionally clueless here. One would expect, given the newness of SDR, that the preponderance of persons on this mailing list would be relatively experienced persons in a related engineering discipline--software, embedded systems, real-time programming, and of course *radio*. It would be reasonable to expect a list like this to offer support to experienced folks who are mostly self-starters, become familiar with Gnu Radio and SDR, to get a few tips here and there about things specifically related to Gnu Radio, publish bugs and oddnesses, etc. But what has happened is that large numbers of people without *any* experience in *any* of the related disciplines come here, expecting a free substitute for a 4-year engineering degree (or equivalent). They pin the success/failure of their project (assigned by their academic advisor, or their manager in commercial situations) on the ability of this list to provide what amounts to free consulting and training. The people on this list who are providing assistance are doing so *as volunteers*. They don't owe anybody anything here. It's a community effort, and the abuse of the good-will of this community is harmful to the community as a whole. I'm not targetting anybody in particular. You know who you are. Knock it off. Now, does anybody know where the power switch on my computer is?:-) -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IQ imbalance...
Per- I also have a xcvr2450 that won't lock sometimes. This is at 2.4GHz. Also an issue about IQ imbalance: I am measuring IQ imbalance. The values are generally quite good. However, one thing I don't understand is that the mirror frequency doesn't turn up on exactely -f but a few Hertz off. I don't get this. Are we sure that the down-conversion on the FPGA is completely turned off ? What size FFT are you using to see the mirror freq? What is the bandwidth of the data into the FFT? From this you could calculate Hz/bin and see if that helps to explain the offset. -Jeff Ian Holland wrote: Hi Matt Yes, -9 dBm is safe. Glad to know it was all safe re input levels. I have not seen the problem locking without trying a lower frequency. What if you try 5 GHz twice in a row? The problem with the not locking to 5G is very intermittent. A few times when it did occur, I tried your suggestion of trying 5G a second time: 2 out of 3 times, it locked the second time. The other time, it did not, but then trying 2.35G followed by 5G did then work. Regarding the other intermittent issue that appeared as IQ imbalance, I have swapped the USRP2/XCVR2450 pair used for transmit with the receive one, and haven't observed the issue since. It may still occasionally occur for the first pair, but this is a workaround for me. I am still confused as to why it occurred to begin with. Best Regards Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: About EEPROM and FX2(68013a) USB interfacein USRP
Catalin- On Mon, Apr 12, 2010 at 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: Date: Mon, 12 Apr 2010 16:02:43 +0800 From: Liang Xin Áºê¿ liangxin...@gmail.com Subject: [Discuss-gnuradio] About EEPROM and FX2(68013a) USB interface in USRP To: discuss-gnuradio@gnu.org Message-ID: o2o2579940b1004120102j64b217c0pf2ff8431da1ca...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi All I am developing a board with gnuradio which is like USRP. It is also use FX2LP(CY7C68013a) and AD9862, and I add some surroundings. I hope that my board can work well with gnuradio, but it seems like it can only support USRP now. So could you please give me some help, if I want to run gnuradio on my board. How should I do with it? ThinkRF (www.thinkrf.com) is also developing GNU Radio compatibility for its product. I have been working on this project for a few months. We're interested in feedback on the approach we took. Our board is also an unconfigured Cypress FX2 on power-up, so we will have a proprietary utility that changes the personality of the board. Once that is done, the board looks like a USRP, presenting the corresponding VID/PID and responding to the USRP USB protocol. We chose to have it show up as a USRP rev 5 to distinguish it from a real USRP, of which I believe the latest revision is 4. Is this likely to conflict any time soon? My suggestion would be to use 4.x and work out with Matt what the x should be... for example you might use 4.6 if Matt says that he's likely to jump a major rev number before he moves the minors to 4.5 This would give the advantage of marking your board with a more-or-less accurate time-frame and capabilities range. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt- My understanding is that it takes 3 BUFGs and one DCM for tri-mode (maybe one more of each for RGMII support but I don't see that) and, between this and other USRP2 needs, you ran into the limit of 8. Is that accurate? Or would 10/100/1000 support would take more than 3... I can't say how many clocks a _good_ 10/100/1G system would need, but the Opencore required 4. One thing to keep in mind is that while there are theoretically 8 global clocks in the S3, other limitations mean that it can be difficult to use all 8. Ok thanks Matt. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt- About Vikram's 10/100 mode question, we were wondering if it's a design flaw; i.e. something wrong from the start in the original opencores.org source, or if it's fixable but hasn't been a high priority item given USRP2's high data rate requirements. But then I found this post: http://www.ruby-forum.com/topic/143084 So I guess the former. If there are any hints you can give on what's wrong, we can take a look. Maybe our guys can get it working. Eventually I got completely fed up with the opencores gige core and wrote a completely new one from scratch (the simple_gemac). It only does gigabit, though. Ok. One of the main problems with 10/100/1000 in a spartan is that you need a large number of clocks and the S3 is constrained. My understanding is that it takes 3 BUFGs and one DCM for tri-mode (maybe one more of each for RGMII support but I don't see that) and, between this and other USRP2 needs, you ran into the limit of 8. Is that accurate? Or would 10/100/1000 support would take more than 3... If you just want 10/100 and can live without gigabit, I would suggest doing that, as it will save 1 or 2 clocks. Ok... maybe we can implement both modes if we're careful. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
George- Did you see my previous post about the accelerator PCIe card? To some extent the Microsoft approach is what we're doing. But we want to stay compatible with USRP2 hardware so we connect GbE to the accelerator card; non MAC-related dataflow is PCIe from there. Buffering required to stay compatible with USRP2 software and high, sustained transfer rates moves right, to the accelerator card (which has a lot of memory). Interesting, I didn't see this post. I tried doing some googling for it but I couldn't turn up with it. What was the subject of the post? Here is the archive copy: http://lists.gnu.org/archive/html/discuss-gnuradio/2010-03/msg00481.html The real trick is software. Our approach is that MAC-related code still appears in GNU radio source, but is marked with pragmas (first something specific to our project, then OpenCL, then OpenMP) so that code actually runs on the accelerator card (the TI multicore CPUs on the acclerator card run arbitrary C/C++ code so they're not limited like an Nvidia or other GPU). We plan to use our GNU radio interface to test results of a server acceleration project we're doing for DoE. That's the long story... right now our short-term objective is the GbE-to-GbE USRP2 connection. So right now you're trying to get low latency, but high throughput, between two USRP2's connected directly via GbE? So you're not using the frontend? No, one USRP2 connected to the accelerator card (which is PCI or PCIe). We want to stay as compatible as possible with all USRP2 hardware. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
George- What I got from your paper is that the matched filter approach for fast packet detection would not work in an OFDM setting. What about fast ACK generation? Would it require an IFFT implementation on the USRP? Would it help much? It's a good question, and something I haven't explored, and I'm not much of a DSP guy. So, I'll punt the question to everyone else who has more DSP experience than me. Both are all about signal detection, both the fast-packet detection and fast ACK generation. So what you want to do is first detect the preamble in the USRP without decoding (because it's complex and takes long). So, we propose using a matched filter on the USRP to detect the packet preamble. In 802.11ab, the preamble was done with BPSK (even if the data is sent using OFDM in 802.11a). With 802.11g, it can be a full OFDM preamble. So, with a full OFDM preamble, you can still detect it with a matched filter, but I'm a little unclear about how to generate the coefficients. You essentially are detecting in the time domain with the matched filter. It might require an IFFT on the USRP... anyone? Dan? :) This all said... I really think we need a better interface to reduce latency. Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board. Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P Is there anything that would prevent GNUradio developers to push the MAC layer functionality on the USRP? The USRP and USRP2, from what I understand, are both tight for space in the FPGA. I'm pretty confident you can't fit an OFDM implementation on the USRP. There are free multipliers and space on the USRP2, but I think it would also be tight, leaving you with not much room for the MAC. Then, you'd be building the MAC in verilog which sucks. Most people who want to do MAC development have CS backgrounds, not EE backgrounds, form which Verilog is black magic ;) To cover a wide range of MAC layer standards at fast RF data rates, some type of processing element is required in the front-end data flow; i.e. before the x86 server. One way is an embedded processor core in the FPGA that runs C code and has a library of useful stuff (matched filtering, iFFT, etc) that look like basic function calls, but are implemented as parallel structures in FPGA logic, outside the processing core. C/C++ code calls the function, waits some number of clock ticks or gets a callback, and it's done (well, more or less). This approach both abstracts the FPGA logic to the C/C++ programmer and gives the FPGA more flexibility (i.e. reduces the number of applications where people need to reprogram the FPGA). I would guess that between Matt and NI guys they're planning (if not already started) on developing a more powerful version of the USRP2, with larger FPGA. My understanding is that Matt originally chose Spartan-3 because it was Xilinx's highest performance FPGA (with reasonable chip cost) that would still allow developers to use WebPACK. Evidently he had to move to S-3 2000 for more capacity, although WebPACK only supports up to S-3 1500. That means that GNU radio users who want to modify the FPGA already need the paid for Xilinx ISE tools... and I can tell you from experience that Xilinx holds its tools in high regard and charges accordingly. For these reasons -- not to mention competition from people like Lyrtech and Sora, maybe something NI guys pay more attention to than Matt -- a USRP2 with Virtex 5 or 6 starts to make sense. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Marcus- On 04/06/2010 09:44 PM, John Gilmore wrote: Which part of the Linux issue... sustained throughput or latency? I wouldn't be surprised to find that latency hasn't improved substantially because it's not a priority for server software. Even VoIP applications are not concerned about a 1 msec improvement... whereas that makes or breaks a wireless MAC. Simple test. Core 2 Duo system, 2.33GHz, Fedora 11. A 1500 byte ping test to localhost yields an average RTT of about 33usecs. That tests most of the network stack except for hardware interfaces, and gives you some notion of best case for latency/turn-around time. If MACs have requirements that are more aggressive than 20-50usec turnaround time, then relying purely on software in a running general-purpose operating system, even on relatively-good hardware may be optimistic. I think there is no way to avoid that MAC-related processing has to be done prior to the server motherboard. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
John- Which part of the Linux issue... sustained throughput or latency? I wouldn't be surprised to find that latency hasn't improved substantially because it's not a priority for server software. Even VoIP applications are not concerned about a 1 msec improvement... whereas that makes or breaks a wireless MAC. I know that in the early days of Linux development, David Miller spent a lot of time making sure that the Ethernet layer could reliably send and receive more than 1 MByte/sec via TCP over 10 megabit Ethernet, and more than 10 MBytes/sec over TCP on 100 megabit Ethernet. I watched his measurements and his kernel evolve to make it happen (learning from and improving on Van Jacobson's early work making 68000-based Sun-2's move 1MByte/sec over TCP on original Ethernet). You might say, That's only 90%, surely he can do better, but that's 90% of the raw bit rate, delivered flow controlled and error-free at the TCP socket layer (all the overhead, from interframe spacing to preambles to CRCs to packet headers, goes in the 10%). As you might expect, pumping the data through required keeping all parts of both systems working in overlap. One packet being assembled to transmit, one received packet being picked apart, and one packet flying on the medium, at all times. If these two software jobs can both run in one packet time, you win (and don't need much if any buffering, keeping latency very low). These code paths were heavily scrutinized and optimized for the common cases. I haven't kept track of who's measuring Linux kernel GigE thruput recently. Here's a pointer to a 2001 study: http://www.csm.ornl.gov/~dunigan/netperf/bulk.html Most people care about TCP speed, but making fast paths for TCP usually makes even faster paths for the UDP packets that USRP2 will be using soon. I can believe Linux Ethernet handling is fast and gets faster all the time... but with most of the emphasis on throughput. I'm still looking for studies that focus on latency; i.e. turn-around time (or RTT), and use recent Linux and motherboards. Probably such data is harder to find becuase in most applications (over long routes), improving RTT at the motherboard + kernel level won't be worth the effort. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt- About Vikram's 10/100 mode question, we were wondering if it's a design flaw; i.e. something wrong from the start in the original opencores.org source, or if it's fixable but hasn't been a high priority item given USRP2's high data rate requirements. But then I found this post: http://www.ruby-forum.com/topic/143084 So I guess the former. If there are any hints you can give on what's wrong, we can take a look. Maybe our guys can get it working. -Jeff Thank you for your email. The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: http://code.ettus.com/redmine/ettus/projects/fpga/repository/revisions/master/show/usrp2/simple_gemac simple_gemac_wrapper in the fifo_2clock_cascade files. which is instantiated in u2_core. Most of the buffering happens in I would just start with the u2_core and simple_gemac_wrapper. If you're not using the SERDES, that is a good place to start ripping out. Does this imply that we can pull out the aeMB core, the 32K RAM and the buffer pool under module u2_core ? To carry out preliminary testing we need to be able to pass data to the gemac and configure appropriate control registers. Could you please suggest what existing modules we could reuse to send data to the gemac ? 3) Do you have an FPGA internal achitecture block diagram of any type? Is there another group you're aware of doing such major modification FPGA work that we might talk to? There were some on the wiki at one time. If they're not still there I'll post a talk I did which covers the architecture. I have looked at the wiki (http://gnuradio.org/redmine/wiki/gnuradio), however i was not able to find any block diagrams for the internal architecture of the FPGA for USRP2. I still might not be look at the right place. Could you please point me in the right direction ? From forum discussions over the past couple of months it appears that USRP2 does not support the 10/100 mode. Could you please help us understand the work effort involved in getting the 10/100 mode working ? Thanks and Regards, Vikram. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
George- Thanks for the reply George. I'm still looking for a little more information on this topic. - What is PMT http://gnuradio.org/redmine/wiki/1/TypePMT - Why was m-block removed http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/msg00066.html - Has anyone measured latency with the USRP2 and GigE I'm not sure. - Is GigE alone not capable of handling MAC turnaround times or is software to blame for this I think the latency is on hundreds of microseconds, which is greater than, say, an 802.11 ACK turnaround time (24us). I would tend to blame Linux and buffering more than GbE itself (MAC + PHY). Here is an interesting doc where the researchers were asking similar questions: http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf I'm not sure yet how much buffering is done in the USRP2 firmware but we hope to know shortly as a couple of our guys are in the process of taking apart the logic, pulling out non-GbE related sections, and rebuilding. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Veljko- I tried with a stop-and-wait ARQ and two USRP2s with XCVR2450s, but the delay was too long and inconsistent. I can't remember the exact figures, but definitely up to milliseconds. Do you mean two USRP2s back-to-back? Or both connected to motherboard ports? -Jeff 2010/4/6 George Nychis gnyc...@cmu.edu: On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick cir...@gmail.com wrote: Thanks for the reply George. I'm still looking for a little more information on this topic. - What is PMT http://gnuradio.org/redmine/wiki/1/TypePMT - Why was m-block removed http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/msg00066.html - Has anyone measured latency with the USRP2 and GigE I'm not sure. - Is GigE alone not capable of handling MAC turnaround times or is software to blame for this I think the latency is on hundreds of microseconds, which is greater than, say, an 802.11 ACK turnaround time (24us). - Is the scheduler the main issue in the way it handles i/o between blocks There are some details of this in the second link I gave. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
George- Jeff, I definitely agree that buffering also adds significant latency. How much of the MAC can you get around? I just think that, there are a number of people who want the flexibility of the SDR, but want to do MAC research, and current common SDR architecture is just not good enough. We need lower latency between the hardware and the host. Microsoft Research recently built up a new SDR which uses PCI-E to address the latency issue: http://research.microsoft.com/en-us/projects/sora/ Did you see my previous post about the accelerator PCIe card? To some extent the Microsoft approach is what we're doing. But we want to stay compatible with USRP2 hardware so we connect GbE to the accelerator card; non MAC-related dataflow is PCIe from there. Buffering required to stay compatible with USRP2 software and high, sustained transfer rates moves right, to the accelerator card (which has a lot of memory). The real trick is software. Our approach is that MAC-related code still appears in GNU radio source, but is marked with pragmas (first something specific to our project, then OpenCL, then OpenMP) so that code actually runs on the accelerator card (the TI multicore CPUs on the acclerator card run arbitrary C/C++ code so they're not limited like an Nvidia or other GPU). We plan to use our GNU radio interface to test results of a server acceleration project we're doing for DoE. That's the long story... right now our short-term objective is the GbE-to-GbE USRP2 connection. BTW, that's a Virtex 5 on the Sora board, that's not going to be cheap. -Jeff Their whitepaper is here: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 I had a paper in the same conference which used several techniques to split common MAC functionality between the USRP and the host to reduce the latency of time-critical functions (e.g., carrier sense): http://www.andrew.cmu.edu/user/gnychis/nychis_nsdi09.pdf I of course believe in my own work, but I also believe that it is not sufficient to cover all MAC implementations and future novel MACs ;) PS. it also has architectural latency measurements (e.g., host - kernel, kernel - USRP, USRP - kernel, etc.)... and I posted the code for these measurements on CGRAN, for those interested. This is why you have the problems you have Veljko, the turnaround time is extremely high. We came up with the approach of fast-ACKs which are generated from the USRP itself. This all said... I really think we need a better interface to reduce latency. Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board. Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Philip- On 04/06/2010 04:19 PM, George Nychis wrote: Jeff, I definitely agree that buffering also adds significant latency. How much of the MAC can you get around? I just think that, there are a number of people who want the flexibility of the SDR, but want to do MAC research, and current common SDR architecture is just not good enough. We need lower latency between the hardware and the host. Microsoft Research recently built up a new SDR which uses PCI-E to address the latency issue: http://research.microsoft.com/en-us/projects/sora/ Is Sora active? The forum seems really quiet. Also they say there is a strict non-commercial use use license. Also, it seems like they are using the RF front ends from WARP, a look at the Warp site suggests the radio board is 2K. Also, they estimate the board price at several K$, so it is not quite WARP prices, but looks to be closing in on it rapidly. [1] I think you're touching on an underlying, basic point: Matt et. al. have spent years developing an RF + server architecture that both works and is inexpensive. Those two things are very difficult to integrate. Many tradeoffs and compromises must be made carefully, with a lot of painstaking trial and error. Matt's followers recognized this some time ago, more recently NI has recognized this. The Sora team may find it difficult -- and likely expensive -- to reliably move very high rate ADC data over some distance, external to the PC. PCIe-over-cable is one way, but again, not cheap. -Jeff [1] http://social.microsoft.com/Forums/en-US/sora/thread/2701a49b-2ea1-4df6-a85c-d5d01b4ea77c Their whitepaper is here: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 I had a paper in the same conference which used several techniques to split common MAC functionality between the USRP and the host to reduce the latency of time-critical functions (e.g., carrier sense): http://www.andrew.cmu.edu/user/gnychis/nychis_nsdi09.pdf I of course believe in my own work, but I also believe that it is not sufficient to cover all MAC implementations and future novel MACs ;) PS. it also has architectural latency measurements (e.g., host - kernel, kernel - USRP, USRP - kernel, etc.)... and I posted the code for these measurements on CGRAN, for those interested. This is why you have the problems you have Veljko, the turnaround time is extremely high. We came up with the approach of fast-ACKs which are generated from the USRP itself. This all said... I really think we need a better interface to reduce latency. Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board. Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Charles- I would tend to blame Linux and buffering more than GbE itself (MAC + PHY). Here is an interesting doc where the researchers were asking similar questions: http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf I'm not sure yet how much buffering is done in the USRP2 firmware but we hope to know shortly as a couple of our guys are in the process of taking apart the logic, pulling out non-GbE related sections, and rebuilding. -Jeff I glanced over the document briefly and was wondering if your analysis of the linux issue was because of this document, or a separate source. I'm only asking because the document is 10 years old and is using RedHat 5 and Pentium 2s. I would assume the linux kernel support for GigE has improved since then. Which part of the Linux issue... sustained throughput or latency? I wouldn't be surprised to find that latency hasn't improved substantially because it's not a priority for server software. Even VoIP applications are not concerned about a 1 msec improvement... whereas that makes or breaks a wireless MAC. What I found interesting in that particular document is the authors were careful not to speculate and to use a logic analyzer to make exact measurements. For me the key figures are GbE (MAC + PHY) and PCI latencies, which are likely not too reducible. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] interfacing a DSP array card to USRP2
Firas- From: Jeff Brower jbro...@signalogic.com Firas- A couple of brief comments: 1) Sounds like this was a high-speed data acq card, optimized for streaming, not an accelerator card. How big was the FIFO? The FIFO was 64MByte. That's huge... and you mentioned a 64k block transfer, much smaller, but still more than 40 times a large Ethernet packet. It sounds to me like this particular card mfg was focused on very high rate streaming (without gaps or drops) and not on low-latency, small transfers. I would guess they didn't set up their driver to optimize small transfer sizes. Maybe even the board didn't support a small size, for example if the FIFO had to contain a minimum number of channels and/or data length before it could assert not empty. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Considerations for new hardware in gnuradio
Per- If we had an fpga image that allowed us to store samples on the USRP2 that would be very benefitial, at least for me. Then one could test algorithms with 100MHz sample-rate. Yes, it would not be possible to use the channel continously. Receiving 1ms of samples would take 4ms to upload. However, using the time-stamp functionality one can synchronize nodes to transmit and receive at the same time and thereby enable testing e.g. interference rejection algorithms. How many samples? I think the USRP2 has a 512k x 16 (1 Mbyte) SRAM that's not used in the default FPGA image. -Jeff Quoting George Nychis gnyc...@cmu.edu: Short but sweet response. It would be great to have a SDR hardware board that works with GNU Radio that has a very, very, low latency connection to the host, like PCI express. Similar to the Microsoft Research SDR (previously named SORA). That would be great and open up possibilities of low latency MAC protocol implementations. Just sayin'! - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] interfacing a DSP array card to USRP2
Matt- We're working on a project at Signalogic to interface one of our DSP array PCIe cards to the USRP2. This would provide a way for one or more TI DSPs to insert into the data flow and run C/C++ code for low-latency and/or other high performance applications. The idea is that we would modify the current USRP2 driver (or create an alternative) so it would read/write to/from the PCIe card instead of the Linux (motherboard) GbE. A few general questions at this point: 1) We would connect the USRP2 to the GbE on our DSP array card. We would want to shift latency/delay downstream to the PCIe card Linux driver interface, and make the GbE-to-GbE interface as low latency as possible. Could you give us some guidance on which FPGA modules handle buffering for host transmit/receive? Is it reasonable we can reduce buffer sizes if the array card GbE has a fast response time? 2) We want to use the GNU radio GMAC as opposed to Xilinx or other off-the-shelf core, our thinking being that we can make contributions to data rate and latency-reduction discussions, as well as tech USRP2 tech support, if we become familiar with your core. Can you give us some guidance on a process to remove non-GMAC related modules from the firmware? Go to the top level and start pulling? Obviously SRAM related, CORDIC, and ADC/DAC interfaces, are not needed. 3) Do you have an FPGA internal achitecture block diagram of any type? Is there another group you're aware of doing such major modification FPGA work that we might talk to? Thanks. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Under Flow
Halidziya- My beagle board is clone and it is working in 200MHZ , but when I run the program it doesn't consumes to much CPU time A Beagle board clone? The Beagle board already costs less than its component BOM. Did you alter the design in some way? Also, why only 200 MHz? That's way slow... what is the reason? -Jeff On Tue, Mar 16, 2010 at 9:59 PM, Jeff Brower jbro...@signalogic.com wrote: Philip- On 03/16/2010 06:51 AM, halidziya yerebakan wrote: Hi all; ? ? ? ? Thanks to Mr. Balister I run USRP on BeagleBoard ( http://www.opensdr.com/node/17) . But it doesn't give any sound when I try to listen FM radio. I think there is some mismatch in sampling rates or data format. I read other mail list archives but they didn't solve my problem. Here is my console : r...@beagleboard:/usr/share/gnuradio/examples/usrp# ./usrp_wfm_rcv_nogui.py Using RX d'board A: Basic Rx gr_fir_fff: using cortex_a8 Freq: 100.1M ? Volume:0.10 ? Setting:FREQ OK aUaUaUaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUuOaUaUaUaUaUuOaUaUaU (No Sound Here goes like this ) Run oprofile, find the code that takes all the time, optimize using NEON, repeat :) The sample rate conversions will be the CPU hogs for this waveform. It looks like you are using an optimized fir filter already, but work through the sample rates at each step. It is possible the audio out is doing another rate conversion. Also, the gnuradio block may create a very long fir filter, you can adjust the filter design settings to reduce the number of taps. It will work, but you do not have many GHz of cpu to cover up in-efficient design decisions :) At what rates are the OMAP 3530 cores running on the Beagle board? ? The web page says up to 600 MHz for the ARM A8 and up to 430 MHz for the C64x+ core. ? Sometimes TI eval/dsk boards don't always run at max rate... Also, do you know if anyone has done work to port GNU radio functions over to the C64x+ core? ? For example you mention sample rate conversion, that would be very suitable to offload onto the DSP. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Sayg?¡Àlar; Halid Ziya Yerebakan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Under Flow
Philip- On 03/16/2010 06:51 AM, halidziya yerebakan wrote: Hi all; Thanks to Mr. Balister I run USRP on BeagleBoard ( http://www.opensdr.com/node/17) . But it doesn't give any sound when I try to listen FM radio. I think there is some mismatch in sampling rates or data format. I read other mail list archives but they didn't solve my problem. Here is my console : r...@beagleboard:/usr/share/gnuradio/examples/usrp# ./usrp_wfm_rcv_nogui.py Using RX d'board A: Basic Rx gr_fir_fff: using cortex_a8 Freq: 100.1M Volume:0.10 Setting:FREQ OK aUaUaUaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUuOaUaUaUaUaUuOaUaUaU (No Sound Here goes like this ) Run oprofile, find the code that takes all the time, optimize using NEON, repeat :) The sample rate conversions will be the CPU hogs for this waveform. It looks like you are using an optimized fir filter already, but work through the sample rates at each step. It is possible the audio out is doing another rate conversion. Also, the gnuradio block may create a very long fir filter, you can adjust the filter design settings to reduce the number of taps. It will work, but you do not have many GHz of cpu to cover up in-efficient design decisions :) At what rates are the OMAP 3530 cores running on the Beagle board? The web page says up to 600 MHz for the ARM A8 and up to 430 MHz for the C64x+ core. Sometimes TI eval/dsk boards don't always run at max rate... Also, do you know if anyone has done work to port GNU radio functions over to the C64x+ core? For example you mention sample rate conversion, that would be very suitable to offload onto the DSP. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] digitizing a digital data stream with USRP2
John- I have a USRP2 and I'm interested in doing an experiment where I'd like to simply use the USRP2 as an A/D and D/A device, essentially disabling the RF tuning portions. The signal I'm trying to digitize is a stream of digital TTL pulses. I assume that the best way to interface to this is through the DC-30MHz LFTX and LFRX daughtercards that would pass DC. Could anyone provide me with additional guidance on how to run this test? Thanks in advance. I'm not intimately familiar with GNU radio hardware and the experts here will hopefully correct me if needed, but I think you would face these issues: 1) The default FPGA logic doesn't offer a demodulation enable/disable, so you'd have to make some logic changes and rebuild. 2) Assuming the A/D converters on the LFTX and LFRX are 8 bits and = 16 bits, then the maximum sampling rate you could move over GbE would be around 60 MHz. Is that enough for your application? If you need faster rates but only in bursts (like a radar situation) then possibly some memory (block RAM) in the USRP2 FPGA could be used for buffers. I'm not sure how much is available... a build without demodulation would probably free up some mem. 3) Continuous streaming to HDD file could be difficult, or at least would require careful configuration of the HDD file system, real-time scheduling and other system considerations, and of course careful programming. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building USRP2 FPGA on ISE 11.4
Tracey- I was able to place and route the design on ISE 11.4 using a 'high' effort and ensuring that the speed grade selected is -5 (that really made a difference of about 20MHz in the speed of the final design). However, when it comes time to generate the bitstream, it complains about the -g Match_cycle:Auto and insists on changing it to -g Match_cycle:NoWait, and then throws an error, with no information. You didn't have to change any source files or the constraints file? No coregen errors? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] article: No-knob radio: the future ofWarfighter communications?
Ettus Guys- http://www.army.mil/-news/2010/01/27/33577-no-knob-radio-the-future-of-warfighter-communications/ No-knob radio: the future of Warfighter communications? After as week, this brings up a question: is there supposed to be an official PR or other announcement about the acquisition on NI's website? I don't see anything yet. I would think that some statement from NI clarifying continuation of open source status and GPL licensing for GNU radio software (and hardware and FPGA logic, very crucial) would be re-assuring to GNU radio developers and users, as well as users-in-planning -- such as US Army guys mentioned below. Unless the acquisition hasn't actually closed yet, then the only thing I can guess that might be holding up NI is if they need to tweak their wording, for example mention items that might be excepted from GNU licensing if they conflict with one of their many patents. The block diagram user interface in GRC would be one possible example. -Jeff Jan 27, 2010 By Sharon Rushen, CERDEC Public Affairs FORT MONMOUTH, N.J. - U.S. Army engineers in collaboration with their Navy counterparts hope to open the gates of cognitive radio development to academia, industry and other DoD organizations by building a universal radio test-bed this year. The Communications-Electronics Research, Development and Engineering Center's Software Defined Radio lab will work with the Navy Research Lab to transfer previous development done on the Joint Tactical Radio System to the GNU Radio's open source, free software environment. Through the GNU platform which is inexpensive and universally accessible, universities, contract companies and government agencies can use a common platform to advance the state of cognitive radio software. The transition to the GNU platform will help ease collaboration efforts with other organizations who frequently opt to use 'grass-roots' hardware for programming due to the comparably high-cost and limited accessibility of JTRS radios. Additionally, the GNU platform will enable the SDR lab to conduct large lab tests and field tests, rather than having to simulate larger-scale network testing. The cost constraints associated with the JTRS radio prohibit larger-scale networking, limiting the number of radios they can test at one time, explained SDR lab team lead, Tim Leising. Through funding provided by the Office of the Secretary of Defense, Director of Defense, Research and Engineering, the SDR lab team will collaborate with the Navy Research Lab, to start building a universal GNU radio test bed this year. Once the test-bed is completed, they will work together to make it remote-accessible using the Defense Research Engineering Network to house the software platform, allowing DoD organizations and external research partners to test their software on it from any location. CERDEC will facilitate a dial-in QA session for media participants to interact with leading U.S. Army researchers involved in developing the GNU test-bed. To participate in the media round table, contact CERDEC Public Affairs: (732) 427-1926. The Communications-Electronics Research, Development and Engineering Center (CERDEC) is one of the research and development centers under the U.S. Army's Research, Development and Engineering Command (RDECOM). The Software-Defined Radio (SDR) lab is part of CERDEC's Space and Terrestrial Communications Directorate. -- de Ken N9VV ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] article: No-knob radio: the future ofWarfightercommunications?
Matt- We have repeatedly made statements about our commitment to continue developing GNU Radio and to open source, both in our original announcement and in several following emails. We employ three GNU Radio developers full time, including Josh Blum who created GRC. I don't know what else you could possibly want, or how else we could possibly state it. Everything I'm hearing sounds good, your statements are re-assuring and passionate. Please forgive me, but I'm just asking where's NI's official statement? Is that not a reasonable question to ask? I checked their website every day this week. I doubt I'm the only one who was doing that. If you read the GPL, you would know that nobody can take GPL'ed code away from you. If the US Army guys in the article below have any concerns, I'm sure they know how to contact me. Not to quibble, but like anything else, GPL code cannot infringe an existing patent. I don't understand your concern about the lack of a press release. The acquisition has closed and we are continuing to go about our normal business. Right now Tom and I are working on MIMO OFDM code. You can follow our ofdm branches in git if you like. Still all GPL. I understand the concern about any significant change like this. However, I would ask you to look at Ettus Research's 5 and a half year commitment to GNU Radio and open source, my personal 9 year commitment to GNU Radio, my personal 12 year track record of contributions to multiple open source projects, the tens of thousands of lines of open source code we have produced, and our multiple affirmative statements of continued support. Yes I know. I recognize this fully. I'm a 50 yr old guy with a long track record in engineering and business in DSP, telecom, and software since I started writing Apple II programs in 1980. In my day we didn't have open source (or the Internet) so we started small companies and learned the hard way about patents and IP rights and acquisitions. When I was a few years younger than you are now I was founding a company after leaving another one I had co-founded, which eventually got acquired in Jan 2004 by NI. So yes I'm old curmudgeon who's seen a lot, which is why I insist on asking such questions. I can see I'm probably being annoying, so I'll keep my questions about an NI announcement to myself from this point. -Jeff On 02/12/2010 04:43 PM, Jeff Brower wrote: Ettus Guys- http://www.army.mil/-news/2010/01/27/33577-no-knob-radio-the-future-of-warfighter-communications/ No-knob radio: the future of Warfighter communications? After as week, this brings up a question: is there supposed to be an official PR or other announcement about the acquisition on NI's website? I don't see anything yet. I would think that some statement from NI clarifying continuation of open source status and GPL licensing for GNU radio software (and hardware and FPGA logic, very crucial) would be re-assuring to GNU radio developers and users, as well as users-in-planning -- such as US Army guys mentioned below. Unless the acquisition hasn't actually closed yet, then the only thing I can guess that might be holding up NI is if they need to tweak their wording, for example mention items that might be excepted from GNU licensing if they conflict with one of their many patents. The block diagram user interface in GRC would be one possible example. -Jeff Jan 27, 2010 By Sharon Rushen, CERDEC Public Affairs FORT MONMOUTH, N.J. - U.S. Army engineers in collaboration with their Navy counterparts hope to open the gates of cognitive radio development to academia, industry and other DoD organizations by building a universal radio test-bed this year. The Communications-Electronics Research, Development and Engineering Center's Software Defined Radio lab will work with the Navy Research Lab to transfer previous development done on the Joint Tactical Radio System to the GNU Radio's open source, free software environment. Through the GNU platform which is inexpensive and universally accessible, universities, contract companies and government agencies can use a common platform to advance the state of cognitive radio software. The transition to the GNU platform will help ease collaboration efforts with other organizations who frequently opt to use 'grass-roots' hardware for programming due to the comparably high-cost and limited accessibility of JTRS radios. Additionally, the GNU platform will enable the SDR lab to conduct large lab tests and field tests, rather than having to simulate larger-scale network testing. The cost constraints associated with the JTRS radio prohibit larger-scale networking, limiting the number of radios they can test at one time, explained SDR lab team lead, Tim Leising. Through funding provided by the Office of the Secretary of Defense, Director of Defense, Research and Engineering, the SDR lab team will collaborate
Re: [Discuss-gnuradio] Ettus Research News
NI has a reputation for fiercely protecting their patents. They sued The MathWorks over Simulink in a lengthy and hard-fought case and won in a jury trial in 2003. This is why, to this day, you can't change source block parameters via dialog box or other visual or control panel means while a simulation is running in Simulink. After that court decision, NI used litigation (or the threat of it) to subdue (or acquire) certain program vendors with block diagram style user-interfaces. My guess is that at some future point, new additions to Ettus radio will be offered under some type of business-oriented licensing model that ensures a software revenue stream for NI (in addition to the radio hardware). That has been NI's model; in following this company since the mid-1980s, I don't see it changing. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus Research News
Don- I'm not going to get all awestruck about the guy. No one is worthy of that. He may be your friend, but this is just business. Nothing personal. After seeing 100s of engineers and projects and companies go by in my 30 years of engineering, I can say you probably ought to be awestruck by Matt Ettus. He's that good. Through creativity, clear thinking and hard work, he's created something extremely valuable to humanity, used by 1000s of developers. On the other hand, I sure hope Matt did his homework on NI and added appropriate conditions in the acquisition agreement. -Jeff Don Fanning wrote: Am I denying that he shouldn't be paid? No. He has done a great bit of work and much congratulations to him for taking his business to the next level. I'm not going to get all awestruck about the guy. No one is worthy of that. He may be your friend, but this is just business. Nothing personal. When someone touts a product that doesn't include all the pieces, then they should be given a chance to respond and make it right. As for my tone: Matt started it. :-) I kinda felt something like this was happening when wouldn't repost the hardware designs back into the SVN. Apparently, I was right to be concerned as should anyone involved with the project. On Fri, Feb 5, 2010 at 1:40 PM, Tom Rondeau trondeau1...@gmail.com wrote: I never do this, but: You have no idea what you are talking about. Please be better informed before libeling a real champion of open source software and hardware and who has done so much for the software radio community as a whole. On a personal level, he's also a very good friend. I will let Matt answer your specific issues, but I find your tone to be insulting and your comments baseless. This is not the kind of community we have been fostering here. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus Research News
Don- But what happens when your project won't fit into the square form factor? What if you have this great idea but can only fit into the form factor of say a cell phone... then what? I'm not the only one with the same idea... Look at the beagleboard guys doing their USRP work. The Beagle board replaces the server, not the radio hardware. Beagle board guys are not working on shrinking the RF circuitry, at least yet. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Ian- Perhaps? We only have two USRP2s and 2 XCVR2450s. However, if it was the SD card, I would think both XCVR2450s should have the problem. Actually, even the better of the two occasionally fails, so I can't be sure. If you rule out the SD card, then is there a way you and Manav can compare PCB revisions for USRP2 and XCVR2450 -- and USRP2 logic revision -- and make sure your systems are absolutely identical? Even a small rework or logic change might make a difference... -Jeff Ya, what I mean is that for you too the problem may be the SD card only. Actually we had got around 20 USRP's/daughterboards from Ettus and none of them were working with the SD cards they supplied with them (20 in all). When I tried with an older SD card, it worked. On Tue, Feb 2, 2010 at 5:43 PM, Ian Holland ian.holl...@rlmgroup.com.au wrote: ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ISE11.1 error using Linux CLI..Update HELP
Matt- We are currently working on a fix for the problems with compiling under the ISE 11. We believe it to be a problem with ISE 11, since the design works fine under ISE 10, but have not gotten very far. Any help anyone can provide on this would be much appreciated. I didn't see ISE 10 vs. 11 threads currently active on comp.arch.fpga, but if you guys start one please mention so we can follow along and possibly contribute in some way. We're not using ISE 11 yet, but we do a lot of ISE and Xilinx FPGA work. Thanks. -Jeff On 01/18/2010 05:38 AM, Mahesh Poolakkaparambil wrote: Hello , I have posted a query on the forum regarding compiling u...@_rev3 on ISE11.1 , I still could not find a good remedy for this. I am attaching the error message with this mail. i hope this will help form some one to help me regarding the problem. Compiling verilog file ../../u2_core/u2_core.v in library work Module atr_controller compiled Compiling verilog file ../u2_rev3.v in library work Module u2_core compiled Module u2_rev3 compiled No errors in compilation Analysis of file u2_rev3.prj succeeded. = * Design Hierarchy Analysis * = ERROR:HDLCompilers:87 - ../../../eth/rtl/verilog/MAC_rx/MAC_rx_FF.v line 134 Could not find module/primitive 'fifo_xlnx_2Kx36_2clk' ERROR:HDLCompilers:87 - ../../../eth/mac_txfifo_int.v line 35 Could not find module/primitive 'fifo_xlnx_512x36_2clk' -- Total memory usage is 131520 kilobytes Number of errors :2 ( 0 filtered) Number of warnings :0 ( 0 filtered) Number of infos:0 ( 0 filtered) Process Synthesis failed INFO:TclTasksC:1850 - process run : Generate Programming File is done I hope to hear a remedy for this problem, Once again thanks in advance, Mahesh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding flow control
Tom- Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ). We greatly appreciate the information and need to think about stuff on our end. I've been deliberately vague about our application (not that I could really explain it even if I felt authorized discuss it). The thing to remember is that we believe (maybe we are fooling ourselves) that we see easily reproducible problems when RX is ON but not when RX is OFF. One more question was just sent to me to pass on, while I was composing this email: crazy idea: is there any way to clock the host, i.e. keep track of a time stamp in the host and gate/trigger the host outputs at a constant sample rate that is consistent with the sample rate of the USRP2? just thought I would throw that out there... Clock the host at multi-MHz rate? One way would be to connect the A/D converter directly to the PC and omit external radio hardware. Then you would not need FPGA de-modulation, GbE, etc. That would be a multi-year hardware and software effort, but sounds like something you and your mystery questioner might be willing to take on ;-) -Jeff On Fri, Jan 15, 2010 at 6:24 PM, Matt Ettus m...@ettus.com wrote: On 01/15/2010 03:08 PM, Tom Gross wrote: yes of course we have two separate gig-e cards. if the usrp2 is sending us pause commands then it seems evident the usrp2 is having trouble keeping up, not the computer. First off, the USRP2 will only send pause frames when you are transmitting, not receiving. Pause frames are not generated due to the USRP2 being unable to keep up. Pause frames are not generated due to the computer not being able to keep up. Pause frames are generated as a normal part of the transmission process. This is fundamental, and you need to understand exactly why. When you are transmitting, the USRP2 can only consume samples at a fixed rate, determined by the clock rate (100 MHz) and the interpolation rate (4 or higher). No matter what that rate is, your computer should be able to generate samples faster than that. Since your computer does not have a 100 MHz clock to pace the generation of those samples, it will generate them too fast. When they are sent the USRP2, which can only consume them at a certain rate, they will pile up in the buffers of the USRP2. Once the buffers get full enough, the USRP2 will send pause frames back to the computer to tell it to wait until the samples it has can work their way through the pipeline. Again, this is completely normal and not because your computer is too slow, and not because the USRP2 is too slow. It is a normal consequence of the practicalities of generating samples asynchronously to their consumption. So in normal transmit operation, you will see large numbers of pause frames going from the USRP2 to the computer. Do not be alarmed. When receiving, the USRP only generates data as fast as samples are created by the ADC clock, divided by the decimation rate. If the decimation rate is 4 then the sample rate is 25 MS/s at 32 bits per sample, or 800 mbits. This fits just fine into gigabit ethernet, and so it all just goes out almost immediately over the ethernet, and nothing ever backs up and stalls. If your computer couldn't keep up, then it MIGHT WANT TO send pause frames, but we have disabled that. Instead, if your computer can't keep up it will drop frames and you'll see S in your terminal window. Get a faster computer or do less processing if you see this. If you were to try a decimation of 3 or lower, then you would be generating more than 1 gigabit per second, and the ethernet wouldn't keep up, and the buffers in the USRP2 would overflow and cause an overrun (O) error. You shouldn't be doing this because it won't work. I hope this has cleared it up. To summarize -- each USRP2 needs its own Gigabit ethernet card to talk to EVEN if it is using only a tiny fraction of the total bandwidth. And those cards need to be configured to honor flow control. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Use of bin_statistics
Adib- Important Note: Beside tunning time depends on the hardware (RF syenthesizer speed), one should remameber that the time needed to collect 1024 samples with decimation rate=8 (minimum USRP decimation) is 128 usec while : Time needed to collect 1024 samples with decimation rate=256 (maximum USRP decimation) is 4.096 msec This means that the tune delay in the case of decimation rate =256 should be larger than that used for deimation = 8. i have a question regarding the above quote, if we are taking 1024 bin FFT, do we need to have 1024 of signal samples? It's not necessary, you can zero-fill remaining samples until 1024. In some analyses, the time domain collection frame size is held constant (it may be dependent on the nature of the data) and the FFT size increased, giving more bins per Hz and an improved view of what's going on. But if you do this, then you may want to apply a Hamming or other window prior to the FFT to avoid a potentially abrupt amplitude cutoff at the zero-fill point. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on iphone?
Cosmin- Hey,Could it be possible to install gnuradio on smarphones or iphone (v1 to v3) -maybe a minimal version- in order to get working the usrp (or a minimal harware) with it?Maybe a custom usrp hardware?Changing the dock for example. Interesting question. The Palm Pre and Mot Droid have OMAP 3430... I know Beagle board can run GNU radio (OMAP 3530) but I haven't heard of a 34xx port. My guess would be that Droid is the best candidate for experimenting. It runs Android and and it might be reasonable to expect peer support for porting complex applications. Palm Pre seems very closed and Palm doesn't seem interested at all in developers doing low-level ARM or DSP core development (we know, we tried talking to them about it). I bet Philip has some comments. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] gnuradio on iphone?
Cosmin- If all you need is a portable software radio package you can reconfigure and monitor (ie, via a screen), Notre Dame is making big strides in that area https://radioware.nd.edu/prototypes/prototype-portable-software-radio Yes I like very mutch this prototype! It looks like on the Cosmos1999 or StarTrek TV series. If you like that one, try this: http://omapzoom.org/ Still needs an enclosure for the USRP, but overall is smaller. Certainly phone like. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem of compiling FPGA bin files.
Juha- Who has had success with 11.x? I'm eager to start working with the usrp2 code, but I cannot get the tools to work. I was on the phone today for 30 minutes with the local Xilinx sales rep and they just won't allow me to get 10.1.03. You can't buy it, you can't get it for free, and you can't even get it unofficially. They only offer the 11.x series ISE. Suggest the following: 1) Tell your Xilinx sales rep to either a) help you with issues in porting from 10.1.03 to 11.1, or b) give you 10.1. His argument is based on expected user ability to port. If he really thinks it's easy, then it's easy for him to help you. 2) Post your specific porting issues on comp.arch.fpga. Xilinx has a couple of guys there who are helpful, plus you are likely to get peer suggestions. Since 1998, my experience has been that each new version of ISE is always a porting headache. This has historically been a fundamental Xilinx issue. -Jeff 2009/12/3 Matt Ettus m...@ettus.com: Some people have had success with ISE 11.1, and some have not. I have not tried it yet, and am still on 10.1.03 which is known to work. Early in the new year I'll be moving to 11.1, but if anyone can figure out the problems, that would be much appreciated. Matt On 12/01/2009 05:36 AM, ÖÜÁÁ wrote: Hi, I tried to use Xilinx ISE 11.1 to open project usrp2/fpga/top/u2_fpga/u2_fpga.ise.There are some files missing,such asfifo_generator_4_1.v . And there are errors when implement design... = ERROR:ConstraintSystem:59 - Constraint NET adc_a[0] LOC = A14 ; [u2_fpga.ucf(1)]: NET adc_a[0] not found. Please verify that: 1. The specified design element actually exists in the original design. 2. The specified object is spelled correctly in the constraint source file. ... ERROR:ConstraintSystem:59 - Constraint NET clk_muxed TNM_NET clk_muxed; [u2_fpga.ucf(216)]: NET clk_muxed not found. Please verify that: 1. The specified design element actually exists in the original design. 2. The specified object is spelled correctly in the constraint source file. ... ERROR:ConstraintSystem:59 - Constraint NET ser_t15 IOSTANDARD LVCMOS25 | [u2_fpga.ucf(336)]: NET ser_t15 not found. Please verify that: 1. The specified design element actually exists in the original design. 2. The specified object is spelled correctly in the constraint source file. ... ERROR:ConstraintSystem:59 - Constraint DRIVE = 12 | [u2_fpga.ucf(336)]: NET ser_t15 not found. Please verify that: 1. The specified design element actually exists in the original design. 2. The specified object is spelled correctly in the constraint source file. ... ERROR:ConstraintSystem:59 - Constraint SLEW = FAST ; [u2_fpga.ucf(336)]: NET ser_t15 not found. Please verify that: 1. The specified design element actually exists in the original design. 2. The specified object is spelled correctly in the constraint source file. How could I fix it?? Thanks! Liang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Halfband filter coefficients help
Ilkyoung Kwoun- Thank you for your advice. Actually I am aware of basic characteristics of half band filter. It is very well explained in Rick Ryon's Understanding Digital Signal Processing (2nd Ed.) ( http://www.amazon.com/Understanding-Digital-Signal-Processing-2nd/dp/0131089897/ref=sr_1_1?ie=UTF8s=booksqid=1257900094sr=8-1 ) The thing I do not have any clue is the 'inner' and 'outer' coefficient things in FIR filter. I guess this is something related to the practical implementation issue rather than the fundamental concept. I did a simple googling yesterday and found a paper. ( http://ce.et.tudelft.nl/publicationfiles/1090_509_shahbahrami_prorisc2005.pdf) I hope I can find a way to get started. :-) Here is a Hypersignal log-magnitude plot showing the frequency response of the two halfband filters (31-tap in blue, 7-tap in red): http://www.signalogic.com/images/gnu_radio_halfband_filters.jpg In the plots I used an arbitrary sampling rate of 25 MHz -- don't know what you're using. Note that both filters have an approx -6 dB point at Fs/4 as would be expected due to halfband symmetry properties. As for inner and outer mention in the Verilog code, I might guess that refers to 2 multiplies needed when filtering a complex signal. As for why there are two (2) filters, one is used for higher rate up/down conversions and the other for lower rate. Firas' documentation has some information on this... also here is QA exchange between Firas and Matt that might help you out: http://old.nabble.com/Some-USRP2-Questions-td20729711.html -Jeff 2009/11/10 Sebastiaan Heunis sheu...@gmail.com Hi I think Brian is just referring to the fact that you can see that the HBFs are implemented as symmetric FIR filters (the coefficients). A HBF is just a special filter that is designed so that the cutoff frequency will always be at fs/2, so if you filter with it and decimate by 2 afterwards (which is why you would use an HBF), you don't get aliasing. Also, the decimation in the CIC filters can be set to a wide range of values, so the HBF will always have to cut at fs/2 regardless of the decimation in the CIC. From what I've read, Goodman and Carey came up with them so you can probably look for some papers if you're interested. Sebastiaan -- Sebastiaan Heunis Radar Remote Sensing Group, University of Cape Town, South Africa Tel: +27 72 950 9370 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] scope display bug? distortion of sine wave athigh frequency
Milo- I found sine waves will be terribly distorted when they are generated at relatively high frequency(above 5khz) from signal source in GRC. I set the sampl_rate of scope sink to 2Ghz(high enough, I think), and there are always spikes on generated sine wave. This problem is especially distinct when generated sine wave reaches 20Khz and the waveform displayed on scope sink is almost saw wave. There will be nothing to dispaly if I keep on increasing frequency to 1Mhz. Is there anybody who met this problem before? or it might only be the display problem in GRC? I guess it might be the problem of scope sink which could not achieve that high sweep (sampling) rate even I set it correctly. Attached are snapshot of generated sine waves at different frequencies: Your plots are probably fine, depending on what is your sampling rate (Fs). Think of it this way: if you display a sine wave near Fs/2 then you only have 2 samples for each sine wave period (1 per peak) and connecting those dots with straight lines on a scope graph will look like spikes, to use your terminology. In the case of your 20 kHz plot, it looks to me like you might have 3 or 4 or so samples per sine wave period, so my guess is your Fs is somewhere between 60 and 80 kHz. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Standalone USRP1 Operation
Firas- Has anyone tried to run USRP1 without PC? I have an application where a friend supported me with a standalone USRP FPGA image. I used the PC only to load this image to the USRP using gnuradio blocks/tools. After that I can plug-off (disconnect) the USB cable from the PC and USRP continue to operate standalone. My question is, has anyone tried to load USRP FPGA image without a PC? For example using a micro-controller (Like Microchip PIC 18F4550 which has USB 2.0 port) with SD memory holding the image? What it takes/need to do so? Altera and Xilinx FPGAs can boot from a variety of small, cheap Flash devices. I haven't looked at the USRP1 schematic in a while, but my guess is that it would take only a few mods to deadbug an appropriate Flash device and jumper as needed. Looking at the board, I don't see that Matt has left a place for the typical header with the required signals, but there are only a few and they should be available on the CY7C680 pins. Programming the Flash device is another question: one way is a socket on the USRP1 and a cheap Flash programmer (connect to PC serial port or parallel port). -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uspr2 working intermittently/segmentation fault
Marcus- It appears that you do not have the current firmware (and possibly FPGA image) installed on the SD Card. Please grab the latest from: http://gnuradio.org/releases/usrp2-bin/trunk/ Eric set-curmudgeon-mode(True) Segmentation Fault on the host should *never* be the correct response to buggy firmware on the USRP2. Ever. Not everything the FPGA does -- register format/contents, FIFO widths, etc -- can be error checked. There has to be some reasonable expectation on the software side. The typical method is a revision id register, the software checks this and adjusts capabilities. If the revision is too far behind or doesn't match expectation then the software gives an error message. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Rev4 FX2 firmware question. InitializingFIFOs ?
Ryan- I have been working on modifications to the USRP board so that I can pass a gating signal through the basic RX daughterboard to gate signal collection for a pulsed radar application. This is somewhat working, but I am having problems with data alignment when stopping and starting the system. It appears that the FX2 chip does not clear its fifo when stopping/starting the system. There seems to be an arbitrary number of data samples left in the buffers when I restart the system, and this causes sample 0 to appear at sample X. Is there a function I can call to manually wipe the FX2 fifos and ensure that they are empty when starting the system? If not, what do I need to do to resolve this; possibly customize the firmware (this looks like a headache)? The FPGA modifications appear to work as expected. These buffers are definitely zeroed upon restart. I have verified most of this by routing important signals through the headers on the dboards to a logic analyzer. Everything looks pretty good from the FPGA's perspective. In DSP based radar related systems I've worked on, gating typically occurs as close as possible to the data acq side, rather than close to the CPU or intermediate data transfer circuitry. Can't you zero ADC input inside the FPGA on the alignment that you need and basically let the system push zeros during the off time? Or some way that avoids stopping/starting the USB chip? Once you stop/start the USB chip I would think there are driver issues to worry about also -- and if you migrate to USRP2, then same thing, except with the GbE PHY. Maybe I mis-understand your objectives; one reason for a full system stop would be power consumption. Is that an issue? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Rev4 FX2 firmware question.InitializingFIFOs ?
Ryan- Could you hack the FX2 firmware and reprogram it to clear its internal buffers and/or reset pointers and counters on Reset? Or if that's already being done, then do it again at some point depending on a signal from the FPGA and/or host driver? I found some threads discussing FX2 firmware changes (for example http://www.ruby-forum.com/topic/106235, http://osdir.com/ml/gnu.radio.general/2005-05/msg00011.html). Cypress and others seem to offer a low-cost eval board for FX2 development. -Jeff In DSP based radar related systems I've worked on, gating typically occurs as close as possible to the data acq side, rather than close to the CPU or intermediate data transfer circuitry. Can't you zero ADC input inside the FPGA on the alignment that you need and basically let the system push zeros during the off time? Or some way that avoids stopping/starting the USB chip? Once you stop/start the USB chip I would think there are driver issues to worry about also -- and if you migrate to USRP2, then same thing, except with the GbE PHY. Maybe I mis-understand your objectives; one reason for a full system stop would be power consumption. Is that an issue? -Jeff Hi Jeff, The gating is done in the FPGA; it simply controls the the decimated strobe signal. I don't want to push zeros because that's a waste of bandwidth that could be put to use (we should be able to run at bandwidths higher than 8MHz, depending on the duty cycle of the gate). The problem, as I understand it at this point, is that the FX2 buffers contain garbage starting up. If you use the C++ library to interface the USRP, you will see that there is always a few hundred samples of garbage when the system is started. This is NOT due to filter delays or anything like that, since these are computed in 5 or 6 samples. We run experiments for several hours at a time, so I don't need to start/stop the USB chip. I simply need to make sure that the system initializes with empty buffers. These buffers should be empty when I start my program, and should again be cleared when I stop my program. Just to provide a little more information: We might, for example, transmit 50usec coded pulses into the atmosphere on a 1 msec IPP, meaning that we repeat this process every msec. Using the gate, I can start sampling at say 100km, and stop precisely at 300km. We might continue this process for 12 hours or more. So I start my program at noon, with empty buffers, and stop my program at midnight, which should, once again, clear the buffers. The gating seems to work as expected, as I said, I am gating the decimated strobe, which simply passes data through the receive chain when the gate is high. This, in turn, fills the fpga receive buffer at a reduced rate, due to the gate. When enough samples are placed in the buffer, the packet ready signal is asserted and tells the FX2 to read this buffer into its own buffer. It seems that this FX2 buffer already contains some samples, if this were not the case, I wouldn't receive a random number of samples that came from another experiment previously run. Long story short, If the FX2 fifos were empty at the system start, I would receive a fixed number of garbage samples due to filling the delay taps in the filters, which is perfectly normal. When the data comes off of the USB bus, we have several buffers that hold one-second data tables, with each table containing a header that describes the parameters related to data taken at that particular second. This table is 2 dimensional, the rows represent the IPP (1 msec in the example I gave earlier), and the columns contain the time samples collected during the gate for the specified ranges. This is all very standard stuff. If the system starts up with an unknown number of samples setting in the buffer, life becomes difficult when trying to align things. I am not 100% sure that this is the problem, but when debugging with a logic analyzer, everything in the FPGA looks good, so this is my best guess, and I think I've seen someone mention this FX2 problem before, somewhere. Ryan -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Implementing the USRP1 in another platform
Pablo- The exact question is: Were, in the python code of the GnuRadio core, can I insert the Driver that i mention? I am reading the python code but i can not find were the code read/send data to the USB (to substitute it with the PCI control code). The other question is were in the Verilog Code can I insert the PCI interface control. The better approach is to run USB to your board and PCI to the host PC. Then the problem is reduced to a PCI driver substitute under GNU Radio -- basically a patch. A medium-complexity FPGA on the board can handle this. If the board also supports GbE interface, then the same approach works for USRP2. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sigh
Bob- It appears that TI has withdrawn the free offering of a linux version of its compilers that I pointed out earlier (in October) at this link. https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/download.html This is very disappointing. Without free tools it makes no sense whatsoever to use TI parts for our projects (OMAP, etc.). They just took a great thing and flushed it down a toilet. The above page requires a MyTI log-in... which most people on the group probably don't have. Is there another link that everyone can see? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using USRP/GNURADIO Commercially
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. If someone were to ask you, the answer is simply it's not my code. The only way you would still be involved is if there was some IP that you owned and licensed to your client. Is there? -Jeff I understand that if you just provide the binaries to a customer, you must give them a means to get the source code, and if they choose to distribute that binary to others, they'll just pass on that original offer and hence you're on the hook for providing anyone with source thereafter. Yes? However... If I provide the binaries source code to a customer (and make it clear that the source code will always be included with any binary I deliver to them), can't I just stipulate that the customer must then provide the binaries source bundled together if they choose to redistribute it? E.g., the offer to obtain the source code would ready something like, you should have already received the source with this binary file; if you haven't, the person or company you received the binary from must provide you with the source. I'm thinking of the scenario here where you're a consultant and work on a bunch of small projects using GPL'd code, but you *always* deliver the full source code along with your binaries to your own customers. Having to then deal with anyone and everyone your own customer chooses to provide the product to then seems quite onerous for a single-man consulting company. I'd appreciate your input; thanks! (Disclaimer: I realize you're not a lawyer and you're just giving your personal interpretation and not professional legal advice on these matters.) ---Joel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using USRP/GNURADIO Commercially
Greg- 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). I was assuming a development contract that specified the client received all rights to the code for which they paid for development. All good points that you make. Thanks. I should have made my assumption clear. -Jeff ___ 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)
Michael- Really, really good questions, well formulated. I'm very interested to see the answers -- or advice -- you receive on the forum. -Jeff Michael Dickens wrote: This is similar to the original discussion from 2004; see, e.g.: http://lists.gnu.org/archive/html/discuss-gnuradio/2004-11/ msg00086.html My dissertation will involve using GNU Radio in some capacity - e.g., through a compatibility layer into the code that I'm writing. The details of my dissertation aren't relevant to this discussion. The compatibility layer file (or set of files) will be the only programming that includes GNU Radio-specific programming; all of the rest of the programming for my dissertation will be of my own development. The compatibility layer is for convenience - to make use of certain, but not all, GNU Radio signal processing blocks (why reinvent a perfectly good wheel?) and certain other features provided by GNU Radio - but is not required for functionality of the rest of the programming. I understand from the afore-mentioned discussion, as well as from reading the GPLv3, that my compatibility layer programming -must- be GPL'd in order to comply with the original license of GNU Radio (since it will use #include some gr header and hence forms a larger work). Can my compatibility layer be LGPL'd, or must the license be GPL to match that of GNU Radio? Does the rest of my programming -have- to be GPL'd, because it -can- (but is not -required to-) make use of my compatibility layer (which must be GPL'd somehow), which in turn makes use of GNU Radio? In order for me to be able to choose my dissertation code's license (which might end up being GPL; I haven't decided), do I need to further separate the programming between my compatibility layer and the rest of the code, e.g., via a pipe or socket (such that these 2 parts can be 'exec'd separately)? In my reading of the GPL-FAQ, it seems like most of the answers are it depends ... thus I'm hoping that someone here might have more precise knowledge. Thanks in advance for any advice! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] /. poll related to GNU Radio
Philip Balister wrote: Congratulations guys, you've hit the big time: http://news.slashdot.org/pollBooth.pl More here: http://news.slashdot.org/article.pl?sid=08/06/09/1612250 with 168 comments so far. A serious, dedicated engineering forum on the same list as WikiLeaks and Tor? Rob Malda, what are you doing. Maybe attempting to add some humor, but I don't think it's helpful. The next thing you know, other pubs will carry something about it, with GNU radio running in the top 5. I would make a serious point that it could be wise to disassociate from entities using GNU radio for questionable purposes. Path Intelligence may be one example. Toby Oliver may be doing everything by the book, and I don't doubt his concept is unique and potentially lucrative. But my 2 cents to GNU powers-that-be is not to endorse or take contributions -- code, money, or otherwise -- from entities that are likely to run into privacy or security related litigation. Those are hot potatoes that don't need to be touched. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM results.
Bob- In your sixteen QAM and other figures I see two effects. Notice just the slightest hint that arcs through the top four constellation points in the 16 QAM is not straight. This curvature is caused by nonlinearity. Your result almost surely can NOT be clock jitter. If you had a lot of clock jitter, the pictures would look much worse. Notice the dispersion gets larger as your proceed away from the origin. This is almost surely phase noise in some oscillator. Phase noise of an oscillator to me means jitter. Can you clarify? Do you mean a sinusoid oscillator that has some issue with shape; i.e. non-linearity? Thanks. -Jeff Per Zetterberg wrote: Dear all, I am experimenting with OFDM between two USRPs. Unfortunately, I am not yet able to master the gnuradio framework so I have made my own implementation. The results are given in the link below. http://www.s3.kth.se/~perz/usrp/OFDM_results.pdf How does this compare with the gnuradio OFDM implementation ? What is the cause of the problems. Clock jitter ?, non-linearities ? BR/ Per Zetterberg ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM results.
Bob- Good to hear from you again. I am distinguishing betwen clock recovery operations in the receiver and the oscillator feeding the down conversion mixers. Even though there is some commonality in the sources for these two DIFFERENT things on the USRP, implementation factors of the clock recovery, how well the DBS-RX takes the up conversion of the oscillator by MANY factors to make the downconversion mixer sources, etc. are almost enough different to be independent noise sources. I believe the clock recovery is working just fine or these pictures would look like crap. The jitter of the constellation increasing with increasing distance from the origin is VERY indicative of angular phase noise in the downconversion oscillators in (say) the DBS-RX. Ok thanks for your explanation. Also I found a Wikipedia page on phase noise that even had a formula to convert to jitter. I understand what you are saying now. -Jeff Jeff Brower wrote: Bob- In your sixteen QAM and other figures I see two effects. Notice just the slightest hint that arcs through the top four constellation points in the 16 QAM is not straight. This curvature is caused by nonlinearity. Your result almost surely can NOT be clock jitter. If you had a lot of clock jitter, the pictures would look much worse. Notice the dispersion gets larger as your proceed away from the origin. This is almost surely phase noise in some oscillator. Phase noise of an oscillator to me means jitter. Can you clarify? Do you mean a sinusoid oscillator that has some issue with shape; i.e. non-linearity? Thanks. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Losing data during long collects
Chris- Is there a way for you to temporarily take file-write out of the equation? I.e. can your code look at the bitstream and know if it remains continuous / intact? The every minute or two thing makes me suspicious that some HDD related thing is going on. 16 MBbyte/sec is around 1 GByte/minute. Jeff, Thanks for your recommendation. I can indeed pipe the output of my data gathering app to the input of my GPS processor and see if the problem goes away. Were you able to verify that? However, I suspect the problem is not HDD related for these reasons: 1. I'm using a 4 disk RAID0 (external eSATA) drive that supposedly can handle the throughput 2. When I was disk bound in the past, I would receive USRP overrun errors. I do not receive these errors when I am presently losing a few thousand samples out of every 480e6 I've seen cases before where the drive does handle the throughput as advertised, but on an average basis. Under sustained, continuous write circumstances, when the drive reaches a new sector, multiple of sectors, or some other internal space boundary, extra time is taken for allocation... or something along those lines. That's why I mentioned the 1 GByte figure. It's been some time since I encountered this so it's just a shot in the dark (happened when working on high speed DSP based data acquisition applications). -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Losing data during long collects
Chris- I've seen cases before where the drive does handle the throughput as advertised, but on an average basis. Under sustained, continuous write circumstances, when the drive reaches a new sector, multiple of sectors, or some other internal space boundary, extra time is taken for allocation... Jeff, Thanks again. Is it ever possible for all of these things to happen: 1. write data to disk using cfile 2. hard drive cannot keep up for whatever reason (new sector, etc) and data is lost 3. A USRP overrun condition does not occur That I don't know. I just mention my experience because -- if it should turn out to have any bearing -- it would apply regardless of the file-write method being used. But it does sound from some of the other posts that you should be able to get it working. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Losing data during long collects
Chris- I'm using the USRP/DBSRX to record data for GPS. GPS tracking demands a continuous stream of data -- dropped bits make tracking impossible. 4Msps of complex data supplies 16 MB/s -- within USB2 bandwidth and my 4 disk RAID0 bandwidth. I record the data using my own c++ version of cfile. I never get an error or overrun condition from usrp_standard::read so it appears that everything is working fine. However, when I process the data it is clear that data is dropped -- approximately a few thousand samples every minute or two. I typically record data for one hour at a time. I read data from the USRP in batches of 8192 16 bit short samples. Anyone have any tips on tracking down why I am dropping data? Is there a way for you to temporarily take file-write out of the equation? I.e. can your code look at the bitstream and know if it remains continuous / intact? The every minute or two thing makes me suspicious that some HDD related thing is going on. 16 MBbyte/sec is around 1 GByte/minute. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UK shops track customers via GNU Radiomonitoring their mobile phones!
John- Danny O'Brien of EFF pointed out this profile of Toby Oliver of Path Intelligence, which uses GNU Radio to build phone-monitoring networks for shops: http://www.cnet.com/8301-13505_1-9734052-16.html Toby Oliver, CEO of Path Intelligence, is based in Portsmouth, England, where he and his wife, Sharon, have built a hugely interesting (and innovative) product on top of the GNU Radio open source project, key parts of which they've helped to fund. Which parts of GNU radio were funded and/or developed by Mr. Oliver and his wife? -Jeff The social impact is covered here: http://technology.timesonline.co.uk/tol/news/tech_and_web/article3945496.ece (text below.) and here: http://p10.hostingprod.com/@spyblog.org.uk/blog/2008/05/path-intelligence-phorm-for-shopping-centres.html (See the comments for pointers to patents and such.) http://www.techcrunch.com/2007/12/14/path-intelligence-monitors-foot-traffic-in-retail-stores-by-pinging-peoples-phones/ Of course, though they say this data isn't correlated with any other info, all it would take is recording what image is taken by the security cameras when an identifiable mobile phone walks by. And with what charge card was used at the cash register when that same phone is standing in front of it. And the license plate number (and the RFID's in the tires) of the car that's going past when this mobile phone passes your reader. Then you have the user's picture, name, credit card info, car registration, and maybe tyre RFIDs; all without the help of the mobile operator. Removing the battery from your mobile phone is going to get a lot more popular, I expect. But at least we'll have free software tools for monitoring what info it's leaking about you when the battery is in. (How much of the Path Intelligence modules are in the main GR repository?) John Shops track customers via mobile phone May 16, 2008 Customers in shopping centres are having their every move tracked by a new type of surveillance that listens in on the whisperings of their mobile phones. The technology can tell when people enter a shopping centre, what stores they visit, how long they remain there, and what route they take as they walked around. The device cannot access personal details about a person?s identity or contacts, but privacy campaigners expressed concern about potential intrusion should the data fall into the wrong hands. The surveillance mechanism works by monitoring the signals produced by mobile handsets and then locating the phone by triangulation ? measuring the phone?s distance from three receivers. It has already been installed in two shopping centres, including Gunwharf Quays in Portsmouth, and three more centres will begin using it next month, Times Online has learnt. The company that makes the dishes, which measure 30cm (12 inches) square and are placed on walls around the centre, said that they were useful to centres that wanted to learn more about the way their customers used the store. A shopping mall could, for example, find out that 10,000 people were still in the store at 6pm, helping to make a case for longer opening hours, or that a majority of customers who visited Gap also went to Next, which could useful for marketing purposes. In the case of Gunwharf Quays, managers were surprised to discover that an unusually high percentage of visitors were German - the receivers can tell in which country each phone is registered - which led to the management translating the instructions in the car park. The Information Commissioner's Office (ICO) expressed cautious approval of the technology, which does not identify the owner of the phone but rather the handset's IMEI code - a unique number given to every device so that the network can recognise it. But an ICO spokesman said, we would be very worried if this technology was used in connection with other systems that contain personal information, if the intention was to provide more detailed profiles about identifiable individuals and their shopping habits.? Only the phone network can match a handset's IMEI number to the personal details of a customer. Path Intelligence, the Portsmouth-based company which developed the technology, said its equipment was just a tool for market research. There's absolutely no way we can link the information we gather back to the individual,? a spokeswoman said. ?There's nothing personal in the data. Liberty, the campaign group, said that although the data do not meet the legal definition of ?personal information?, it had the potential to identify particular individuals' shopping habits by referencing information held by the phone networks. The receivers together cost about �20,000 to rent per month. About 20 the units, which are unobtrusive, cream-coloured boxes about the size of a satellite dish, would be needed to cover the Bluewater
Re: [Discuss-gnuradio] Proposal Draft: Next Generation Digital VoiceCodecs and Vocoders for Amateur Radio
Bruce- We've been working on a new lowlatency codec for speech and music, CELT, and are about to public a paper on it. (celt-codec.org). While CELT wouldn't be useful for narrowbanded voice some of the components of CELT would be very useful in an AMBE killer. (Particularly CWRS, the algebraic vector quantizer). CELT itself could be used for a 10-20khz wide mode (40-60kbit/sec with decent SNR) to replace FM with something with much greater quality if there was interest... But a lower bandwidth mode will be far more interesting. Would this be useful to solve the garble problem when there's a firefighter with a loud chainsaw in the background? That just kills the codecs they use on APCO 25 right now. If the codec can handle music and other audio signals besides speech, then the answer is probably yes. That would mean the codec uses perceptual techniques, which are general, rather than specific technique based on a human vocal tract model. The vocal tract model is what gets codecs like AMBE and MELPe into trouble when they encounter non-speech sounds. MP3 uses perceptual techniques. But like Gregory said, lower bandwidth operation is key. Without that codecs like will AMBE persist. MELPe goes as low as 600 bps. Essentially they accomplish this by making a wide range of assumptions based on speech-like signals. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MRFM (Magnetic Resonance Force Microsocopy) andGNU Radio
Jon- The UW Quantum System Engineering Laboratory has written code for Magnetic Resonance Force Microscopy (MRFM). The code is available from http://staff.washington.edu/~jon/gr-mrfm/ Some of the code might be useful to other GNU Radio users. On the FPGA side, there is a 2-stage biquad filter with 24-bit (not 16-bit) data path and filter coefficients. There is also an input multiplexer and adder. On the host side, there is code (in Python with SciPy) that transforms transfer functions, expressed as ratios of polynomials with floating point coeffcients, into cascaded biquad stages with scaled integer coeffcients. The host side code acts as a server, so it can communicate with the MRFM experiment software over TCP/IP sockets. There is a sample client, also in Python with Scipy. I have put links to our site on the Wiki OurUsers and OtherCode pages. I'm curious .. what do use the 'biquad filters' for? I assume you mean that you've implemented a 4th order IIR filter? If so that would mean somewhat non-linear phase depending on the IIR design type. What type are you using? Elliptic? Other? Thanks. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MRFM (Magnetic Resonance Force Microsocopy)andGNU Radio
Jon- I'm curious .. what do use the 'biquad filters' for? I assume you mean that you've implemented a 4th order IIR filter? If so that would mean somewhat non-linear phase depending on the IIR design type. What type are you using? Elliptic? Other? The pair of cascaded biquadratic filters form an optimal cantilever controller. Our experiment software calculates the controller transfer function, a ratio of polynomials with four numerator and four denominator coeffcients (floating point), using the methods described in the papers linked to our page at Cantilever controller design is discussed _here_ ... Our software refactors and scales that transfer function into two biquad filter stages with 24-bit integer coefficients. So I guess the filter type is other. Some phase compensation is included in the transfer function, as described in the papers. Ok thanks. A fascinating use of the USRP hardware. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio on PCI-104 (i.e., Fedora onUSBFlash Drive)
William- -Original Message- From: Jeff Brower [mailto:[EMAIL PROTECTED] Sent: Thursday, May 01, 2008 11:55 PM To: Bahn, William L Civ USAFA/DFCS Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] GnuRadio on PCI-104 (i.e., Fedora on USBFlash Drive) William- Isn't there an issue of how much GNU radio can actually do on a Pentium M system? The Lippert board you mention looks like it's limited to 1 GHz or less with passive cooling. I assume this is a mil app, but you can use fan cooling? What will GNU radio actually be doing? It's for an initial aerial demonstration of our keyless jam-resistant encoding. We are keeping it really, really simple. The airborne unit (the one using the Lippert board) will be toggling between running a C program that generates a waveform packet and then calling GnuRadio to broadcast that packet in the 2.4GHz ISM band using OOK. The packet will consist of nothing more than a timestamp and some additional junk data to fill out the message string. The ground station will sniff the spectrum and record and decode any packets it finds. If that goes well, then the bad guys will start jamming the spectrum and we want to see how much energy, relative to the UAV, they have to expend before they jam us - that they will jam us is not an open question, just how much energy it takes them to do so. The things you guys do at USAFA. I hope Red team has some smart guys and makes it competitive. If these are Sr. engineering students then it sounds like a really good learning experience. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] GnuRadio on PCI-104 (i.e., Fedora on USBFlash Drive)
William- Isn't there an issue of how much GNU radio can actually do on a Pentium M system? The Lippert board you mention looks like it's limited to 1 GHz or less with passive cooling. I assume this is a mil app, but you can use fan cooling? What will GNU radio actually be doing? -Jeff Thanks for the response. More questions below. Bahn, William L Civ USAFA/DFCS wrote: I need to get GnuRadio up and running on some PCI-104 embedded processors, which means I need the O/S to boot from a USB key. I have a 4 GB key but am willing to purchase an 8 GB or even a 16 GB key if that's what it takes. What embedded processor? If it's x86, it won't be a problem. Otherwise, you could be in for a world of fun. ;-) The PCI-104 has 1 GB of DRAM. ummm, do you mean PC/104, like here [1]? No. The PCI-104 is a modified form factor that has a PCI connector instead of the ISA connector. We are using Lippert's Cool RoadRunner 4 which uses a Pentium M Processor. An alternative would be: Does anyone know of a Linux distro that can be made to run from a USB key that we can get GnuRadio up and running on without too much heartache. We've tried installing it on DSL (Damn Small Linux) but can't get the fftw libraries to compile. I've installed both Gentoo and Ubuntu to thumbdrives. I see install directions for GnuRadio for Ubuntu, but don't see anything for Gentoo. As I look over the instructions for the various distros, they seem quite different, so I wouldn't know how to even start trying to install it on Gentoo. So I'll try Ubuntu first. The easiest way to do it would be to pull the hard drive from a laptop, boot from the Ubuntu CD, and plug in the thumb drive (should be the only disk in the laptop in order to avoid accidentally overwriting the boot sector of other drives). Then proceed with install. Is accidentally overwriting the boot sector on the hard drive something that is super easy to do? I would rather not get into tearing someone else's laptop apart if I can avoid it. So what is the sequence I am looking at doing here? Is it something like: 1) Use a laptop that has a CD drive and install Ubuntu onto a thumb drive on that machine. 2) Boot the PCI-104 machine using the thumb drive. 3) Install GnuRadio onto the thumbdrive on the PCI-104 machine. How do I handle the various drivers that are needed for the PCI-104 machine? Can I create a boot thumbdrive on one machine and use it to boot a very different machine? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Photo of the Beagle Board and USRP
Brian- On Fri, Apr 25, 2008 at 9:32 AM, Jeff Brower [EMAIL PROTECTED] wrote: You are talking about the ARM9 core on the OMAP device, right? If so then you can run Linux on the ARM core but overall processing capability will be limited compared to a Xeon or Core2-something PC. Now if you can migrate signal processing tasks to the C55x DSP core on the OMAP, then you're in business. For anyone who is wondering, OMAP series devices are widely used in cellphones and other very low power consumption hand-helds -- the chip series is one of TI's major breadwinners. The OMAP on the beagle board is one of the new OMAP3530 which have a Cortex-A8 and a TMS320C64x+ DSP core. Features of the OMAP can be found here: http://focus.ti.com/docs/prod/folders/print/omap3530.html#features The Cortex-A8 has the NEON SIMD co-processing available to it. Details can be found here: http://www.us.design-reuse.com/articles/11580/architecture-and-implementation-of-the-arm-cortex-a8-microprocessor.html Another interesting tidbit is the graphics accelerator (which I believe is really just another ARM core?) may also be able to offload some of the processing that may want to be done. It may not be able to handle 4MHz bandwidth serial-tone equalized waveforms, but you should be able to take a couple FFTs in real time which is enough for OFDM. Thanks Brian. Yes the 64x+ core is TI's top of the line. The most powerful device they have is a 6-core 64x+ device (look for TCI6486 or TNETV3020) on the web. But 64x+ sucks more power... so have to see whether the new OMAPs end up in Nokia phones or not. In this case TI's target market can probably be described as more generic wireless terminals. If TI would come out with native, factory-supported Linux running on their DSP devices, then they could get in the open source game. As it stands they're on the sidelines, and people like ADI and Freescale are working their way in. On paper the Beagle board looks like a good candidate for embedded GNU radio, but taking advantage of the 64x+ core would take substantial DSP work -- a level that only would apply for a commercial product. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
Greg- 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.) rmsMy 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. I understand completely your viewpoint. However, let me point out that one of your key objectives should be to increase popularity of GNU Radio software. One way to do this is to encourage and support GNU Radio software examples that interface with MATLAB in some way. There is no denying that 1000s of developers are using MATLAB as a tool to develop radio and other RF applications. I'm active on MATLAB lists and forums, and besides commercial developers, I see literally 10s of student questions about RF projects every day. OFDM, MIMO, xxSK, you name it... Professors have assigned them to do it. If you can draw those developers and students (and Profs) into the GNU Radio environment and introduce them to what you're doing, it will only serve to further your goals. However distasteful from an ideological standpoint, I might suggest to take a page from Bill Gates: add low-level compatibility for other RF software to GNU Radio software (typical examples such as transfer data, call MATLAB functions, MATLAB-callable functions), and eventually the others will discover how much better, well-supported, and dynamically growing is your GNU Radio software. -Jeff 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] Matlab interface to USRP
Pedro- I understand completely your viewpoint. However, let me point out that one of your key objectives should be to increase popularity of GNU Radio software. One way to do this is to encourage and support GNU Radio software examples that interface with MATLAB in some way. Yes, you are right in that, but the person that originally posted did not like to use GNU Radio; He wanted to interface USRP to Matlab directly without GNU Radio in the middle (in fact he managed to interface Matlab with GNU Radio). USRP developers/users perhaps would like a USRP-Matlab direct connection, but GNU Radio developers/users surely not. This is the original post: Ya I know, I had read the original post. I would say that it's not possible to have it both ways, there is either basic encouragement for GNU Radio interface with MATLAB or there is not. I think drawing the line at not providing support for interfacing MATLAB directly to USRP hardware is fine, although I would note that over the years people have interfaced MATLAB to many types of data acq/DSP/FPGA hardware that originally didn't support MATLAB. It happens. Even in these borderline cases, people who see the bigger picture -- especially the Professors and instructors who influence our future engineers -- will clearly see the advantages of USRP and start asking what happens if we use GNU Radio. Any increased awareness of GNU Radio is a good thing. -Jeff - Original Message - From: Pu, Di [EMAIL PROTECTED] To: discuss-gnuradio@gnu.org Sent: Wednesday, April 09, 2008 12:03 AM Subject: [Discuss-gnuradio] Matlab interface to USRP Hello all, 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! IMHO, Pedro Ignacio Martos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
Greg- On Wed, Apr 9, 2008 at 11:38 AM, Jeff Brower [EMAIL PROTECTED] wrote: [snip] I understand completely your viewpoint. However, let me point out that one of your key objectives should be to increase popularity of GNU Radio software. One way to do this is to encourage and support GNU Radio software examples that interface with MATLAB in some way. There is no denying that 1000s of developers are using MATLAB as a tool to develop radio and other RF applications. I'm active on MATLAB lists and forums, and besides commercial developers, I see literally 10s of student questions about RF projects every day. OFDM, MIMO, xxSK, you name it... Professors have assigned them to do it. If you can draw those developers and students (and Profs) into the GNU Radio environment and introduce them to what you're doing, it will only serve to further your goals. [snip] Which is a role which the Octave embedding interface should be able to serve reasonably well, without bumping into the philosophical (and potentially legal) problems of linking matlab into GNU Radio. If octave didn't exist then perhaps the argument would be different ... But octave does exist and it is largely matlab compatible .. So to support embedding matlab in-lieu of octave wouldn't just be gratuitously promoting propritary software, it would be promoting propritary software to the exclusion of free software. On days that I'm in philosophical mode, I completely agree. But the reality is that MATLAB is far more widely used than Octave. MATLAB is at the core of the commercial and academic RF community, Octave is not. If we are to increase awareness and popularity of GNU Radio, there is no escaping MATLAB compatibility. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
Matt- I think the problem is that there are basically 2 separate cultures here. There are those coming from the CS and free software world, and those coming from the radio, engineering, academic, industry, hardware, etc. worlds. Those in the free software world often don't understand how truly separate the two cultures are. While everybody has heard of Linux, they usually haven't heard of GNU, RMS, GPL, or freedom as applied to software. For example, I often have people talk to me about the GNU Project, when they really mean the GNU Radio Project, so I take the time to explain that the GNU project is actually much bigger than just GNU Radio. When someone comes here from that second world, where the lingua franca is Matlab, and we immediately hit them with a moral argument without any background, it doesn't help anybody, it just scares them off. I think a better response would be something along the lines of: If you are very comfortable in the Matlab world, then perhaps you should try Octave, which has a high degree of compatibility with Matlab. A link between GNU Radio and Octave would not be difficult at all. However, there are many other free programs which might also function in a similar manner and be even easier to work with, like scipy, matplotlib, and scilab. Most people here just use GNU Radio without all that other stuff because it fits their needs without anything else added on. Is there any particular reason that you need to use Matlab? Is GNU Radio missing any particular features? For a number of reasons, many people here choose not to use proprietary software. Some of those reasons are outlined here: http://www.gnu.org/philosophy/philosophy.html I know that a lot of GNU Radio users and even contributors started out using Matlab, Simulink, LabView, or other proprietary packages. If they are scared off before they get to that point we all lose. I agree with Eric, well said. My one exception is your reasoning based on what features MATLAB and/or GNU Radio have or don't have. If you ask colleagues why do you need to use MATLAB they will say because it's what their company has available, what their colleagues use, it's a widely accepted technical programming language for publishing papers, etc. If you ask students, they will say because my Prof said so. A lot of pragmatic reasons. As you said, a moral argument (or in my terms, an ideological argument) isn't going to accomplish much. But if GNU Radio gracefully plays with MATLAB, at least at the data exchange and function-callable level, then you open the door for the other culture to walk in -- and discover just how far GNU Radio software and hardware has advanced. That's a great way to attract new adherents and supporters. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
more two cents I love Matlab and I use it every day but there is a time and a place for it and it is not as an computational engine for a software defined radio. Signal processing for an SDR is just not the right use for it. It just can't keep up. If you were generating complied code in simulink for some real time target OS via the real time workshop with the intent of interfacing with the USRP I could see the application but just streaming data into Matlab for processing is just using the USRP as a cheap sampling scope frontend. I would hope the USRP is more than a cheap front end to a digital scope. I know alot of people use it(USRP) for this but the real work and beauty of this project is the signal processing blockset and framework to allow the construction of a radio. I think the effort should be put into moving the GNU radio code forward not trying to support a sideline application. I know I will be in trouble with Eric for posting on this subject again... I would point out to Jeff Long that MATLAB has always been intended for simulation, not real-time operation. Everyone knows it can't keep up. The synergy of using it with GNU Radio would be to simulate a system before coding/implementing it entirely in GNU Radio. The common example is a block diagram where MATLAB is handling a few (typically new/advanced/experimental) blocks in the middle, with GNU Radio everywhere else, including RF analog I/O. Then at some point the simulation works and the focus moves to real-time operation without MATLAB. It's been this way for years with many types of DSP and FPGA hardware/software set-ups. Get it simulated first, then move blocks out of MATLAB, one-by-one. One advantage of this technique is it provides a known good to fall back on for debug purposes. I'm not commenting on merits of MATLAB vs. or merits of proprietary vs. free, I'm just saying that the start with MATLAB simulation approach is very common in the RF (and signal processing) developer communities. Supporting that approach with GNU Radio would only be advantageous to GNU Radio. -Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Maxwell Sent: Wednesday, April 09, 2008 2:42 PM To: Jeff Brower Cc: Matt Ettus; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Matlab interface to USRP On Wed, Apr 9, 2008 at 2:24 PM, Jeff Brower [EMAIL PROTECTED] wrote: I agree with Eric, well said. My one exception is your reasoning based on what features MATLAB and/or GNU Radio have or don't have. If you ask colleagues why do you need to use MATLAB they will say because it's what their company has available, what their colleagues use, it's a widely accepted technical programming language for publishing papers, etc. If you ask students, they will say because my Prof said so. A lot of pragmatic reasons. Thats fine for them. I endorse their use of matlab. Three cheers for them. Fantastic. As you said, a moral argument (or in my terms, an ideological argument) isn't going to accomplish much. But if GNU Radio gracefully plays with MATLAB, at least at the data exchange and function-callable level, then you open the door for the other culture to walk in -- and discover just how far GNU Radio software and hardware has advanced. That's a great way to attract new adherents and supporters. It's also a great way to make GNU radio useless to anyone who can't afford matlab. As I was told on IRC every researcher has access to matlab, so of course if GNU radio deeply integrates matlab then many people will incorporate Matlab-only features into their projects since the mindset is every researcher has access to matlab even though far from everyone does... Why bother? There are hardware decks specifically built for matlab which are less costly than USRP. ... and a USRP driver for matlab could probably be written with comparable effort to matlab support in GNUradio. If someone simply wants some compatibility for their own matlab language code, there is octave.. but it seems that idea is being categorically rejected because what is wanted is just a shim to use USRP from matlab. Their needs could probably be best served by a USRP driver for matlab. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question: Setting Rx-A and RX-B Daughterboardon simultaneously
Jason- Unfortunately, it didn't. I would like to know how to get data from the two sides of a SINGLE Rx Daughterboard. Currently, I have a daughterboard at the RXA side of the USRP. I want to get data from both input ports of that single daughterboard. Is this possible? Could I ask you not to cut the previous text from your post? I can't read the question you are answering. Thanks. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 JTAG functionality [was Exposing more JTAG functionallity in FX2firmware]
On Mon, Mar 31, 2008 at 11:46 AM, Uwe Bonnes [EMAIL PROTECTED] wrote: Hello, has there been any effort to expose more JTAG functionality via the FX2 so that the USRP FX2 firmware could be used with modified other JTAG software, like xc3sprog. As far as I can tell, not without some hardware modification. According to the schematics found here: http://gnuradio.org/trac/browser/usrp-hw/trunk/usrp/interface.pdf?format=raw The JTAG section of the FPGA is pulled either high or low and has no other connections. You're obviously free to do what you want with your hardware, but I don't think you'll get much extra support from the mailing list? I could be wrong, so please have at it! This reminds me of a question I have about USRP2. My understanding is the USRP2 has a Xilinx Spartan 3, which I don't think come in anything other than BGA packages. Hopefully Matt brought the JTAG lines out in case people want to deadbug a header and use standard tools. Even better would be the 0.1 holes to install a header if desired. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 JTAG functionality [was Exposing moreJTAG functionallity in FX2firmware]
Matt- This reminds me of a question I have about USRP2. My understanding is the USRP2 has a Xilinx Spartan 3, which I don't think come in anything other than BGA packages. Hopefully Matt brought the JTAG lines out in case people want to deadbug a header and use standard tools. Even better would be the 0.1 holes to install a header if desired. Yes, the JTAG header is on the USRP2. Thanks Matt, sounds good. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Eric- I got the DV Dongle friday and it seems to work. I downloaded an application to decode DStar on the computer but DStar is not very popular in the area yet. I have not decoded any DStar voice so far. I only did a AMBE loopback test. I got concerned because all the application software I downloaded on the dv dongle website was closed source with no mention of the open source firmware or GNU licenses. All the various voice rates in the test software are gone. It appears to be DStar only. There is a link on the dvdongle.com website pointing to the open source firmware project but the link does not mention firmware source. It is possible the makers locked out non-DStar voice rates before taking the product commercial. I asked on the DV Dongle Yahoo Groups list and it appears there is no developer's SDK. There is no documentation on using what appears to be a UDP to ascp daemon. A person replied to my query and said all IMBE rates are available. But given the events I wonder if anyone has tried other rates. It seems the makers are trying to make it difficult to use this device for non-DStar stuff. It also appears the company making the DV Dongle is violating the terms of the GNU License. None of the materials in the box or on the website mention it uses GNU tools and that source is available. There is a link to source code but the link description does not mention source code and it goes to another site. So it will likely be a week or so before I can test the device due to writing and debugging an ASCP driver. It looks like I am on my own in figuring it out using the provided documentation. Can you clarify for me, why should the DV Dongle contents be open source? What GNU licensed code are they using that requires them to give back? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Eric- APCO Project 25 has quite a number of standards documents. If you look at a list for vocoders: ANSI/TIA/EIA 102.BABA Vocoder Description ANSI/TIA/EIA 102.BABB-A Vocoder Mean Opinion Score (MOS) Test ANSI/TIA/EIA 102.BABC Vocoder Reference Test ANSI/TIA/EIA 102.BABD Vocoder Selection Process ANSI/TIA/EIA 102.BABD Vocoder Selection Process Tapes I have not looked at these standards to see the level of detail. There are other parts of the standard that deal with compliance on a system level. http://ftp.tiaonline.org/TR-8/APIC/FSITG/CAPPTG%20(06-08-004)_TIA%20102%5B1%5D.CABC-A(draft).doc I was recently involved in testing a device to a standard where a third party creates the test suite and grants the certificate. Using a AMBE or other codec chip is part of the hardware versus software decision. We want to do everything in software but there are limitations. For example, the functions of the Maxim chip used in the USRP DBS tuner could be done in software if there was sampling rates above 4Gsps and the computing power to handle it. A hardware solution is used because of these limitations. Because we can peek into the IMBE black box and know that it can be easily implemented in software we tend to discount a hardware solution. It is much like the situation with the HDTV decoder where current PC hardware can not do all the decoding. If a hardware MPEG-2 decoder was used, then it could be done, but it ruins the all software solution. Agree. In the open source voice community, many times I see people try to cram something into software, even though they know it's would barely fit or likely would not. In some of the more flagrant cases I've seen, after spending great time and effort, the end result is poor voice quality (usually due to increased latency), unstable system that crashes or hangs easily, and code that is dependent on server characteristics. They're so determined to avoid a hardware solution they end up with no solution. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Gregory- You guys do realize that the 'hardware' AMBE solutions are just software running on a TI DSP, don't you? Have you been following this thread and mention of TI DSPs, other low bitrate codecs that run on TI DSPs (MELPe), etc? We were speculating on which underlying TI chip that DVSI had ROM'ed for their IMBE implementation, which should answer your question. Unlike filters or RF mixers wisely implemented in the analog domain for reasons of physics, dynamic range, and component availability AMBE is available only on chips in order to protect the ability of some to profit at the expense of freedom and flexibility for users of the technology. (I'm making no argument here about the ethics of limiting people's freedom in order to maximize profit, only pointing out the irrefutable fact it is being done. Being that this is *GNU*Radio perhaps I should be, however). My context in making a point about when to use software vs. hardware is solely from an engineering perspective -- get it working correctly, well and reliably, without wasting time. Know when to make the tradeoff, and move on. As good as x86 processors are and continue to become, clearly they waste millions of transistors on motherboard and software compatibility, leaving many weaknesses to be exploited by specialized chips. DSPs, FPGAs, many-core network processors are examples that highlight the situation. These vendors continue to thrive, doing better every year, just as does Intel. As for DSPs specifically, Intel has been trying to convince people of a compute world without DSPs since 1995, when they came up with NSP. Obviously it's not going to happen as long as they are tied to support for standard OS's and motherboards. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Eric- Can you clarify for me, why should the DV Dongle contents be open source? What GNU licensed code are they using that requires them to give back? The DV Dongle device uses open source firmware. Do you mean inside the Dongle? If so, which firmware? It appears the manufacturer is not following the provisions of the GNU license as documentation in the box and the www.dvdongle.com website mentioned in the documentation has no mention of the open source firmware, GNU licenses or directly provides the source code. I am surprised that there is no open source project for the PC side of this device. I would start one but have not written too many Linux or Windows drivers. I need to find a driver guru to join the project. The SDR-14, SDR-IQ, and DV Dongle use the same ASCP protocol. My initial thinking is doing libascp libraries to handle the low level stuff. I was thinking of getting a SDR-IQ. Is it Moetronix that is promoting the ASCP (Amateur Station Control Protocol) protocol? I can find very few references to it. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Eric- Can you clarify for me, why should the DV Dongle contents be open source? What GNU licensed code are they using that requires them to give back? The DV Dongle device uses open source firmware. Do you mean inside the Dongle? If so, which firmware? From the information on the DV Dongle list the shipping firmware is the same as on the moetronix.com web site. http://www.moetronix.com/dvdongle/ Hmm. Yes it does seem they are saying everything inside the Dongle is open source. But I don't see how they can do that since as far as I know, DVSI has never provided open source for IMBE or AMBE. I'm going to guess that if you pin down Moetronix, they will tell you the open source refers to the Atmel 91SAM7S microcontroller that's in there, not the TI DSP. I would further guess that since there is a hardware 'boundary' between the Atmel and the DSP (most likely one of the McBSP simple synchronous serial ports found on many TI DSPs), they will tell you they don't face a GPL requirement to show the DVSI source. I.e. it looks like a brick and they don't know what's in it. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Rick Are these publications actual C code, along with input/output test vectors that can be used to verify bit-exact performance of a software implementation? This is not a reference implementation. The documents describe the algorithm(s) down to the bit level. It is not tied to a specific programming language or processor. The decision as to how to manipulate the bits (C, asm, or FPGA) is up to you. All the standardized codecs that I know of, both ones with IP rights requirements and free ones, provide a reference design, typically fixed-point C code plus test vectors. I wonder why DVSI has not done the same. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hello everyone. I am a new here. I have somequestions.
Alex- I was posting to GNURadio about an year ago but I got busy and then I stopped. I have again started reading about GNURadio and hope to devote my free time this entire year on GNURadio. So I have started reading Discrete Time Signal Processing by Oppenheim / Schafer / Buck. Chapter 4/ Page 168 says : - x_s(t)=x_c(t)s(t) =x_c(t) Sigma ( from n = -inf to inf ) [ delta (t-nT) ] Through the sifting property of the impulse function , x_s(t) can be expressed as : x_s(t) = Sigma (from - inf to inf ) [ x_c(nT) delta ( t-nT) ] Now this version of the sifting property is for the DISCRETE impulse function NOT the continuous Dirac delta function, but just before the discussion starts it says that delta(t) is the unit impulse function or the Dirac delta function. Is this a typo ? Shouled this have been the discrete delta function? If it is'nt, how do the above steps hold? Well, if you have the first printing, you can check here first: ftp://ftp.prenhall.com/pub/esm/electrical_and_computer_engineering.s-045/oppenheim/DTSP/errata1pph.pdf But otherwise, my comment would be... a typo in an Oppenheim Schafer book? 9 years after being published and after countless peer reviews? And you found it? One thing for sure is you're not lacking audacity and enthusiasm. Keep going. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
David- On Fri, Mar 21, 2008 at 04:23:00PM -0500, Rick Parrish wrote: Jeff Brower wrote: All the standardized codecs that I know of, both ones with IP rights requirements and free ones, provide a reference design, typically fixed-point C code plus test vectors. I wonder why DVSI has not done the same. Perhaps the APCO and TIA committees did not require it when the algorithm was published ten years ago. I'm sure there was a bit of negotiation to get the best available vocoder technology and still preserve MIT's and DVSI's interests. A full reference implementation in C would have been immediately employed by a variety of entities seeking to use the technology without the royalties and control DVSI and MIT wanted - anything published like that would have been impossible to control. I agree, however it's very easy to get C source for G729 and other standard, widely used telephony codecs. Yes, the G729 IP rights holders have battles to fight and have had to take steps, such as consolidating and hiring a manager to handle licensing and monitor illegal usage (Sipro). I suspect with the advent of Asterisk and other open source voice software, we're just waiting for a commercial outfit who's made it big using open source and is handling 100,000s of channels at multiple installations -- but without paying the required $10 per channel -- to get sued by Sipro or their constituents, such as NEC and Siemens. And history indicates they made a choice that served their interests well - radio hobby and hacker and far east clone (read Chinese copy) use of P25 IMBE on a PC or in unlicensed hardware has not been a major issue for 10 years, though no doubt more than a few versions do exist outside of official DVSI licensees. It is hard to believe this would have been true if the standard came with C source code... regardless of its license status and the formal restrictions on using it. All good points. But that's a path leading to non widespread popularity and non-adoption into worldwide standardization bodies. With MELPe, NSA has far more serious concerns than MIT + DVSI, with major national security implications. NSA has chosen a 2-prong approach: a) provide access to voice codec standards but hold the line on encryption, and b) carefully control who has access to C source (approved agencies and commercial organizations within NATO and PfP countries so far). Unlike DVSI, reference code and test vectors are important to them because so many disparate entities need to interoperate. And this has no doubt made it easier to collect revenue from the hefty fees for licenses... if only because at least some major users haven't been as annoyed by hobby software that scares their law enforcement customers away from P25 + IMBE as they no doubt would have been if unofficial copies of the C from the standard were available and in wide use in PC radio hobby software. It is at least probably true that at least two common VHF/UHF non P25 digital radio systems that currently are not supported by readily purchased scanner would be readily monitorable by the general public if IMBE source was available, even with the potential patent infringement involved - and I am sure this hasn't escaped notice. Well, without encryption any voice codec is a clear channel if there is strong motive to build a product that can decode. I have no doubt that a community / group effort could easily and quickly produce C source for IMBE if there were sufficient motives (profit, fame, beat Microsoft, etc). -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Rick- Is this a DVSI licensed and publically available closed source module or something unofficial or not generally available to the world at large ? It has obviously long been possible to recode some reverse engineered DSP chip based IMBE implemenation into C++ source code for Wintel/Unix/BSD use, but this would not be free of license and patent issues... and could not be made part of an open sourced project or product without a DVSI deal (and it appears they don't see this as in their interest). Reverse engineering - at least for two common IMBE variants (P25 and MA/COM's ProVoice) - isn't necessary. Both algorithms are published by DVSI through the TIA. Are these publications actual C code, along with input/output test vectors that can be used to verify bit-exact performance of a software implementation? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Eric- - Start Original Message - Sent: Wed, 19 Mar 2008 23:29:57 -0400 From: David I. Emery [EMAIL PROTECTED] To: Rick Parrish [EMAIL PROTECTED] Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device On Wed, Mar 19, 2008 at 07:38:13PM -0500, Rick Parrish wrote: Jeff Brower wrote: If you're looking at low bitrate codecs for GNU radio, why use a hardware (dongle)dependent solution? You might look at MELPe, which provides 600, 1200, and 2400 bps,and can be implemented as a software solution. MELPe is a US/NATO standard (STANAG4591). Common applications are HF radio and L band satellite apps where bandwidth is very limited. My interest is what is actually being used - which in the case of public safety communications is the P25 variant of IMBE. FWIW, a closed source PC hosted IMBE vocoder exists now. Is this a DVSI licensed and publically available closed source module or something unofficial or not generally available to the world at large ? It has obviously long been possible to recode some reverse engineered DSP chip based IMBE implemenation into C++ source code for Wintel/Unix/BSD use, but this would not be free of license and patent issues... and could not be made part of an open sourced project or product without a DVSI deal (and it appears they don't see this as in their interest). Hello, In the case of the DV Dongle they buy the DVSI chips and designed a USB interface to connect to a PC. DVSI gets paid for their work. It is a neat solution for the problem of providing PC and Network support for D-Star. The open source part is the interface to the CODEC chip. It is similar to the MadWiFi drivers where there is a closed source HAL provided by Atheros and the open source part is the interface of the HAL to the OS. Not the best solution but otherwise there would be nothing. Have you seen one of the IMBE dongle codec chips up close? Is it a TI DSP, maybe something like a TMS320VC5509, or similar? DVSI typically uses TI DSPs. I'm wondering, because IP rights issues for MELPe go away for 2400 bps rate if a TI chip is used; TI will normally waive royalty fees in that case. Maybe a similar approach could be taken for MELPe, it would be cheap and not tied to a radio receiver or other equipment. Just a dongle for GNU radio. -Jeff DVSI does make a PC solution for their licensees. I have the APCO P25 Voice Module for my WinRadio G305e and it is keyed to the radio serial number. Because the DV Dongle has a published API I was able to see that it should be possible to run the CODEC at different rates. That is one area of exploration I want to do. I also want to see if the AMBE codec can be used on a IMBE stream. I have seen comments online that they are totally different yet I also see comments from the TIA P25 group that the AMBE codec is an improvement over the IMBE codec and it should be implemented by equipment makers. This seems to indicate that the stream format is the same at least at P25 rates. I find that new products of a company tend to be built on past products of the company. Companies tend not to throw out stuff that works if it still works on the new products. So the improvements could be in the quality of the encoding and decoding rather than changes in stream formats. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Eric- This picture of the prototype shows it is a TI chip. http://www.moetronix.com/dvdongle/ The problem is it may be a ROM or protected Flash version of the DSP chip. I paid for a AMBE codec so I do not want to destroy the internal programming, Yes it's probably a ROM'ed version, but it's only 100-pin so it's too small for 54x or 54x device, unless much older. My guess is a member of the C24x series, which has onchip ROM or Flash, low-power enough to live off the USB, and some stern security features. However this could be used for another project using a TI DSP for a MELPe dongle. The DV Dongle could be a defacto standard for external CODEC interfacing. The Moetronix board/DSP could not be used, but a similar design with a TI DSP, USB interface, and Flash EEPROM is simple enough. The problem with making it entirely open would be NSA's export restrictions on MELPe. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Rick- I am also thinking of writing a APCO P25 Voice to AMBE2000 frame converter and see if the device can decode P25 as well. This may be a general IMBE and AMBE codec. I hope so. I looked at this a while back. What concerned me most was the AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. Compare the docs to another DVSI product - the VC55 - to see what I mean. If you're looking at low bitrate codecs for GNU radio, why use a hardware (dongle) dependent solution? You might look at MELPe, which provides 600, 1200, and 2400 bps, and can be implemented as a software solution. MELPe is a US/NATO standard (STANAG 4591). Common applications are HF radio and L band satellite apps where bandwidth is very limited. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Jared- speex is nice. I've used it as well as the AMBE2000/2020. I wasn't in love with the AMBE. We ended up doing lots of hacking to make the DVSI AMBE 2000/2020 pair of DSPs work in our application. Specs were light and idiosyncrasies were numerous. What was the lowest bitrate you used with Speex? My understanding is that Speex's PESQ scores are below 3 for anything below 3000 bps. -Jeff Date: Wed, 19 Mar 2008 09:02:46 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device CC: discuss-gnuradio@gnu.org On Wed, Mar 19, 2008 at 07:02:08AM -0600, Jeff Brower wrote: Rick- I am also thinking of writing a APCO P25 Voice to AMBE2000 frame converter and see if the device can decode P25 as well. This may be a general IMBE and AMBE codec. I hope so. I looked at this a while back. What concerned me most was the AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. Compare the docs to another DVSI product - the VC55 - to see what I mean. If you're looking at low bitrate codecs for GNU radio, why use a hardware (dongle) dependent solution? You might look at MELPe, which provides 600, 1200, and 2400 bps, and can be implemented as a software solution. MELPe is a US/NATO standard (STANAG 4591). Common applications are HF radio and L band satellite apps where bandwidth is very limited. -Jeff Unless something has changed, MELP is also encumbered. How about a free codec, such as speex? http://www.speex.org/ Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Delay
Per- After implementing Eric's advice, please post the minimum delay value you obtain. I'm interested to hear. Thanks. Changin the fusb_* parameters didn't change my results. By reducing the buffer size (of the reads and writes) the delay is reduced down to around 1ms (I have some problems with underruns and they are more frequent when I use small buffer sizes - still for short runs (0.25sec) its quite OK ). Thanks Per. This gives some idea of a range of typical in-to-out delay to expect (1 to 7 msec). -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
