Re: [Discuss-gnuradio] USRP design is free
If you thought you bought a motherboard from Ettus under the terms that you were getting schematics and PCB files and blah blah blah, fine. If you didn't get them, point to the line item on the receipt or the clause in the contract and take it up with Ettus. I don't understand why people are complaining that the Ettus Research board designs aren't free. They are free. Matt publicly announced that he intended to release them under the GPL. Right up to this day, the schematics (in PDF) are trivially downloadable from http://www.ettus.com by clicking Download on the homepage. Even the schematics for their brand-new products like the N210. Now I will admit that in the past, Matt and Ettus Research provided not just PDF schematics (that you'd have to re-enter manually into a schematics editor) but also netlists, .sch files, a BOM, etc. They never published layout files for directly making your own boards. I don't know when or why the policy changed, and all that were left were PDF schematics. Printed PDF schematics certainly don't qualify as the source code under the GPL (which defines source code as the preferred format for making modifications). There was some discussion on the list at the time of the National Instruments acquisition, in which Matt basically said, sorry, was reorganizing the web site and mislaid 'em. Does anyone know if they ever came back after that point? Being less of a trust-the-web kind of guy than some (after being burned by various things disappearing on me), I saved a copy of the original USRP1 schematics from its 2005 release: Date: Wed, 12 Jan 2005 11:45:10 -0800 From: Matt Ettus m...@ettus.com To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] USRP schematics and layouts I have posted the USRP and daughterboard schematics and layouts on http://www.ettus.com -- just go to the download page. If you are interested in making your own daughterboards, these will serve as a good reference. More docs will be forthcoming. If you want a copy of those schematics, I've put a copy here: http://www.toad.com/gnuradio/usrp-mboard-20050112_tar.gz http://www.toad.com/gnuradio/basic-dboard-20050112_tar.gz http://www.toad.com/gnuradio/parts-20050112_tar.gz I'm sure that many tweaks to the boards have been made since then. If you want to make serious use of these, you'd better compare them to both the current published PDF schematics, and to a recent physical board. At the time these were published, the USRP was new and it had very few daughterboards. By the way, the USRP board took well over a year to develop, and went through several prototypes. Large parts of the free GPL'd GNU Radio software were developed by Matt and Eric simultaneously while building these prototypes. Before the USRP, you needed an expensive and painful PCI oscilloscope board to use GNU Radio -- and then you needed an external tuner. That's what we got the original GNU Radio FM-radio and HDTV receivers working on. The USRP revolutionized ham SDR by being half the price of the PCI board, allowing laptops instead of only desktop computers to be used for the processing, and allowing many cheap RF daughterboards to be made. John Gilmore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Low-cost hardware options
Also upgraded to the next speed-grade of the ADC, to give 40Msps... You spec'd only a 12-bit ADC. In my naive view, resolution seems like it's more important to SDR than samples per second. Resolution is how you avoid losing weak signals when you are of necessity sampling a wide band. Can we improve on this to get a 14- or 16-bit ADC, perhaps with a lower sampling rate, at a reasonable price? As I recall from early USRP days, clock jitter makes a real mess of doing anything important with an SDR. If you can't trust your clock, you don't know when your samples happened, which makes all the computation a lot fuzzier. That's why the USRP didn't synthesize its sampling clock -- nobody back then built a synthesized clock that had low enough jitter. Does this ADF4351 qualify? And what kinds of interactions are there between that clock and the clock on the ADC? Shouldn't the downsampler and the digitizer both be using the same clock, or a clock that's derived from the same clock? Is there a way to use i2c programmable width filters instead of the 20 MHz lowpass filters, to narrow the bandwidth of the signal being digitized down to just the range of interest? This would help ameliorate the low-res ADC by filtering out nearby loud-yet-uninteresting signals. Finally, don't assume that a USB3 chip will easily support downgrading to a USB2 connection. It ought to be that way, but might not be. The EZ-FX2 chip does support both USB1 and USB2, but in the last ten years, nobody ever got around to programming the USRP firmware to actually make it work with USB1. That became somewhat moot as USB2 became standard in everything. Similarly, the GigE interface on the USRP2 has never supported downgrading to 100 Mbit Ethernet, even though that's part of the GigE spec. However, now that they've switched to using a UDP-based protocol rather than an Ethernet-frame-based protocol (finally - hooray!), you can plug the USRP2 into a switch. Switches all allow 10, 100, and 1000 Mbit/sec Ethernet to communicate. If you're going to put 1GE on this device rather than USB2 or USB3, I suggest including a switch chip too, so it will transparently talk to any speed of Ethernet. GigE is still too uncommon on laptops these days. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Open-Hardware
If one desired USB instead, then a simple [Cypress] EZ-FX2 USB-2.0 card with an FMC connector on it, and whatever logic was necessary to grab samples from the ADC could be designed and built. By the way, USB3 is now hitting the mainstream, with PCI boards, motherboards, disk drives and USB sticks from all the major vendors. It provides a significant bandwidth boost over USB2 (it's designed for 3Gbits/sec, both ways simultaneously). This would be very useful to any newly designed USRP-like device. I haven't investigated what chips could replace the EZ-FX2 in a USB3 USRP. Oddly, the Cypress site seems to know nothing about USB3 devices! John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP question for report on gnuradio history
Eric Blossom adapted MIT student Vanu Bose's pspectra (parallelized spectra) software into the first GNU Radio software. That software used a PCI digitizer board, I believe from National Instruments, but it was expensive and not very flexible. We knew of much better digitizer chips, but there was no convenient way to integrate them into a PC-based system. Matt Ettus as working on a Bluetooth chip or macrocell at a commercial company at the time. He noticed the GNU Radio effort, and got interested in contributing. He and Eric designed the original USRP prototypes and modified the GNU Radio software to be able to talk with it over the USB bus. They also designed the daughterboard system and defined the electrical and physical connections to the daughterboards. They released the design under free licenses. Matt ultimately left his job (after finishing the Bluetooth design) and started Ettus Research to reliably produce the USRP, enabling low cost and high performance radio work with GNU Radio. It was a lot of work (he was a 1-man operation and it grew only slowly) and I'm glad he's been well rewarded over the long run for doing it. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] s/Eric/Tom/g
As some of you know, I've been involved with GNU Radio for a long time. The idea that became GNU Radio started as a conversation over dinner in San Francisco with John Gilmore, something like 10 years ago. As one of the guys present at that dinner in early 2001, let me suggest that Eric has done an incredible job picking up that idea and running with it for a decade. We saw that commercial companies were using digital signal processing to radically simplify and improve their products, but that the free software world hadn't learned those lessons. That meant there was a real opportunity hanging wide-open. Eric jumped on it. Part of the deal was that I'd pay his salary for the first year or two, because I knew you can't really get much public support or financial support for a free software project until it can actually do some useful job. Eric spent the first year learning modern signal processing, surveying existing hardware and existing free software, then settled on MIT's spectra/pspectra code base as a good place to start hacking. After the first few years, he found enough academic and commercial support for GNU Radio that I didn't need to pay him full time -- and he weaned himself fully off my support shortly afterward. Matt Ettus was an early volunteer who also saw the real-world promise in free signal processing software. We had reasonable software, but the available high speed A/D and D/A hardware cost thousands of dollars and was pretty lame. Matt finished his job designing Bluetooth circuitry, and then risked everything to design and build what became the USRP. With Eric's help, he built up from nothing to a one-man design/procurement/manufacturing/stocking/shipping/sales/customer-support/programming shop, which over the years has matured into the thriving and valuable business it is today. Jay Lepreau was another early contributor who saw how GNU Radio could enable active academic research into cognitive radios. Jay brought us into his lab at the University of Utah, encouraging researchers at dozens of other institutions to design their experiments on GNU Radio and the USRP. He brought us into the academic funding that significantly matured GNU Radio's ability to do packet-based communication. Jay died in 2008 but his contributions live on in this community. Along the way we took a few detours into application areas that tested and honed GNU Radio's strengths. While Hollywood was trying to force the FCC to outlaw TV receivers that could receive free over-the-air digital TV signals (because they'd forgotten to put DRM into them), Eric and a small team successfully implemented an HDTV receiver using old PCI-bus digitizer boards and GNU Radio. Hollywood's engineers said it couldn't be done, and we knew they were liars, so we did it. Indeed, it ran 30x slower than realtime on a dual Athlon motherboard. But it ran, decoded actual TV signals, and proved to the regulators and to the standards committee that you'd have to not only outlaw hardware demodulators, but also software -- which EFF had recently proven to a Federal appeals court was a violation of the First Amendment. The fucking bastards at the FCC passed the regulation anyway (https://secure.wikimedia.org/wikipedia/en/wiki/Broadcast_Flag), but the American Library Association and Public Knowledge litigated in federal court, proved that the FCC had no authority to regulate what receivers do with their signals after reception, and the rule was struck down. This HDTV demodulator code is *still* not running in the latest version of GNU Radio, but I hope someone will work out the kinks. Modern hardware should be able to do it in realtime. A second big attempted application area was passive radar. We read that the US Army's favorite tactic when invading somewhere was to blow up all the TV and radio stations because it's easy to track airplanes by watching their signals bounce off the planes. It works with cellphone tower signals, too. Eric spent several years researching the topic, writing GNU Radio code, and designing antennas and hardware. Ultimately none of it worked reliably; it took more dynamic range (or custom differential hardware) than we had, but we learned a lot and have made it easier for future generations to do this as the hardware improves. Eric, it's been a great decade, and I'm looking forward to the next big trouble you get into! John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Brief tags describing each source file
I like your ideas! Anyway, I'm still missing the \file \brief doxygen tags for the files. These are extremely useful when browsing through a mass of unknown source material. Otherwise you have to read the source in depth to find out what the sourcefile is all about. But most GNU projects only give the GPL legal information on top. When I was maintaining GDB, I found it very handy to put a one-line comment at the top of each file, like this: % head -1 c*.[ch] == call-cmds.h == /* ***DEPRECATED*** The gdblib files must not be calling/using things in any == c-exp.c == /* A Bison parser, made by GNU Bison 1.875c. */ == charset.c == /* Character set conversion support for GDB. == charset.h == /* Character set conversion support for GDB. == c-lang.c == /* C language support routines for GDB, the GNU debugger. == c-lang.h == /* C language support definitions for GDB, the GNU debugger. == cli-out.c == /* Output generating routines for GDB CLI. == cli-out.h == /* Output generating routines for GDB CLI. == coff-pe-read.c == /* Read the export table symbols from a portable executable and == coff-pe-read.h == /* Interface to coff-pe-read.c (portable-executable-specific symbol reader). == coffread.c == /* Read coff symbol tables and convert to internal format, for GDB. == command.h == /* Header file for command-reading library command.c. == complaints.c == /* Support for complaint handling during symbol reading in GDB. == complaints.h == /* Definitions for complaint handling during symbol reading in GDB. == completer.c == /* Line completion stuff for GDB, the GNU debugger. == completer.h == /* Header for GDB line completion. == copying.c == /* == Do not modify this file!! It is created automatically == corefile.c == /* Core dump and executable file functions above target vector, for GDB. == corelow.c == /* Core dump and executable file functions below target vector, for GDB. == core-regset.c == /* Machine independent GDB support for core files on systems using regsets. == cp-abi.c == /* Generic code for supporting multiple C++ ABI's == cp-abi.h == /* Abstraction of various C++ ABI's we support, and the info we need == cp-name-parser.c == /* A Bison parser, made by GNU Bison 1.875c. */ == cp-namespace.c == /* Helper routines for C++ support in GDB. == cp-support.c == /* Helper routines for C++ support in GDB. == cp-support.h == /* Helper routines for C++ support in GDB. == cp-valprint.c == /* Support for printing C++ values for GDB, the GNU debugger. == cris-tdep.c == /* Target dependent code for CRIS, for GDB, the GNU debugger. == c-typeprint.c == /* Support for printing C and C++ types for GDB, the GNU debugger. == c-valprint.c == /* Support for printing C values for GDB, the GNU debugger. % head -15 c-valprint.c /* Support for printing C values for GDB, the GNU debugger. Copyright (C) 1986, 1988, 1989, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. This file is part of GDB. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of [...] I suspect that if you, Moeller, submitted a patch that added a similar comment to every GNU Radio source file that you understand the function of, it would be accepted. And might even inspire others who understand different files to add their own insights. And some maintainer or volunteer might someday complete the task for all the files, and revise the coding standards to require it on new files. For me, the gnuradio is less a hacking library, but more a solid basis for student education, research and experimentation. The great thing about free software is that one guy can push it in a direction they choose, like becoming a better educational tool. All it takes is time, work, and some coordination. In rx_timed_samples.cpp the URSP-device is hard-wired, as a uhd-derived class. uhd::usrp::simple_usrp::sptr sdev So, once compiled, it can only support the USRP-type. I would prefer to leave this dynamic. I agree, and have been concerned about this aspect of GNU Radio for years. Moeller, do you have a design for how it should work? If the community doesn't hate your design, are you willing to implement it? John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Software mobile phone
Dear All, Do we think it is possible to create a software mobile phone using the USRP, with the OpenBTS code or something else? I mean everything would be in software, plus the USRP? It is absolutely possible. So far I don't know anyone who has tried to do it. The OpenBTS code would give you a big head start. I also think it would be interesting to port the resulting code into a mobile phone. Generally the GSM protocols in a phone are run in a baseband processor separate from the user interface processor. Every phone I know of uses secret, proprietary code running in the baseband processor, even when the user interface is largely free software. Once you had working code running in GNU Radio on a Linux machine, the challenge would be finding a well-documented baseband chip (in which the manufacturer tells you where to find the radio I/O gear on the chip, and how it works, etc). Porting clean GSM code to run in that chip in realtime would require some adaptation to exploit unusual on-chip DSP hardware, mastering an embedded debugging environment, and perhaps shrinking the memory consumption of the GNU Radio-based code. I think it's not only doable, but well worth doing. It should be worth a couple of PhDs at least. You would certainly know the GSM protocols inside and out by the time you were done! John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wimax
evaluating the possibility of start a Wimax fuzzing test bed project with Gnu Radio/USRP . . . the goal is to do with the Radio what we do with software in Fuzzing stage of security related projects . to conduct a huge series of tests , examine the results and see when and how the Radio is not up to the task Sounds like a great idea. (For those who don't know, fuzzing involves sending subtly or wildly wrong values in every field in a protocol, testing how the receiving device handles the error. Fuzzing attacks against Unix command-line utilities found hundreds or thousands of implementation errors by sending, e.g. lines containing millions of characters; negative, zero, or huge length values; non-ASCII character sets, etc, etc, etc. Some fuzz is randomly created, finding bugs that humans never conceived of looking for. But after the first round of fuzz testing, throwing totally random values at a protocol seldom exercises all the code paths in less than an aeon; most of the garbage is rejected at the front door. Fiendish software testers with intimate knowledge of the protocol involved can create constrained fuzzers that smuggle randomly erroneous data deep into the heart of the receiving system before it explodes.) If you write this code, products in the market that it addresses will evolve to become better hardened against both mistakes and attack. But note that deploying fuzzing systems against targets you don't control (e.g. other peoples' infrastructures or mobile devices) is often considered a hostile act and could lead to criminal penalties (or war, if done by one country to another). As for WiMax, I don't know who (if anyone) is working on it in GNU Radio. - there are SDR based projects preferably based on GNU Radio , to fuzz Radio systems : GSM BTS , Wimax Radio , TETRA base stations , etc . The OpenBTS code implements a GSM base station; this code could easily be improved to fuzz GSM handsets. Anecdotal reports from the developers indicate that it's pretty easy for a buggy base station to tickle numerous bugs in handsets from every manufacturer. (Indeed, real-world base stations appear to need workarounds for known bugs in common handsets.) The creation of a GSM handset fuzzing program would probably improve that situation dramatically. It would also make possible a powerful denial of service attack on the cellular networks, making large numbers of existing cellphones crash in their users' pockets. OpenBTS doesn't currently have a GSM *handset* protocol stack (you can't currently emulate a GSM handset with GNU Radio.) Adding that capability would be very useful -- and would probably eventually lead to the code actually *running* in freed handsets. (The baseband processor code in modern cellphones is often the last bastion of proprietary software in the phone -- because there's no free software choice that works.) If someone improved OpenBTS to include a GSM handset stack, then that stack could be improved to fuzz GSM base stations, which would lead to better-hardened base stations. John Gilmore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
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. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
If our library is providing a standard call to set the timestamps of returned samples, shouldn't the standard or default way to do it result in those timestamps being accurate wallclock UTC realtime, rather than counting up from zero or from a random number? If by default our streams of samples came back with accurate nanosecond timestamps, that would be a big plus in the long run. You could later sync up signals from receivers all around the world; recordings would contain the time when the signal was received; etc. Any computer on the Internet can easily sync using NTP to within about 10 ms or so, to set the high order bits. And anyone with a PPS clock hooked to their USRP would get real cesium-linked timestamps. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MA (Memory Acceleration) and SR-DVB in Karlsruhe, @ WSR10
Vincenzo, I read your new teaser on Memory Acceleration. Time/memory tradeoffs, yes, have done that. Recursive table aggregation, OK. Algorithm segmentation, sure. I am still looking forward to the real paper, when it gets released. But I have a structural question. We've now seen two major projects that use the USRP, libusrp, and the general software signal processing paradigm of GNU Radio. But they both totally abandoned the GNU Radio code base. Both SR-DVB and OpenBTS wrote their own code from scratch, even though major parts of the computation could have been handled by GNU Radio processing blocks. Why? Does something about the structure of GNU Radio doom it to only be used in experiments and demos? Is the problem in the complex, multi-language realtime high level structure, or the low level block processing structure, or somewhere else? Perhaps it was a legal issue, that both projects initially thought they didn't want to license their code under the GPL? (OpenBTS has since changed its mind.) Will techniques like memory acceleration be usable in signal processing blocks embedded in the GNU Radio signal processing framework? Or does its basic signal flow structure make it an inappropriate host? If so, what should we do about this? Have we made it too hard to use GNU Radio as a subroutine library for the functions close to the hardware (like tuning and demodulation), letting them be called from a custom main program that includes custom code for parsing and managing higher level protocols? How can we make it simpler to build big projects on GNU Radio and produce reliable and efficient production-quality programs? John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmit legit, become a ham
Nothing forces you to interact with other ham radio operators. You can happily work in isolation communicating among your own stations if you wish. Unless you need to do frequency coordination, which you usually do. Then you have to deal with the oldest, gnarliest hams around, the ones who 50 years ago got access to mountaintop towers and have been squatting on them ever since, like trolls under bridges. However, ham-land contains a ready pool of technically inclined people, most of whom are interested in but not well informed about subjects like software defined radio and Free Software. I got a ham Tech license in the 1970-80's and it was one of the more disappointing experiences in my life. What a culture clash! The ham fraternity was filled with people who spent all their time chit-chatting on their handheld radios about their personal lives, but who knew and cared very little about radio technology or computers. (Nowadays everyone has cellphones, but in those days they were the only ones who could communicate mobile.) They fought uselessly over stupid little status things like how short or long your callsign was. I soldered together a 1200 bps packet radio interface board, ran BBS's, evolved protocol software, and taught classes on digital radio communication protocols to the interested part of the local Bay Area ham community (led by Hank Magnuski, KA6M). The almost universal attitude among the hams who I met was We got here first, we own these frequencies, don't you put any funny computer stuff on 'em because that will just attract more of the public to horn in on our monopoly. They actively threatened to turn me in to the FCC for any real or imagined violation of the incredibly picky rules, like letting someone else log in over my radio modem (carrying third party traffic). Really friendly folks. I decided to retire my ham license until a large number of the existing hams died off (many were middle aged or older). Perhaps now the worst jerks have cleared the ranks, and some more welcoming people are hams; I don't know. I moved my digital radio experiments to the unlicensed bands, ignored the hams, and have been much happier ever since. I think the hams are still doing 1200 bps FSK, while the unlicensed folks have evolved to 108,000,000 bps WiFi. There must be tens of thousands of hams nationwide. There are tens of thousands of WiFi nodes in San Francisco alone -- and no crazy restrictions about not using encryption, not letting other people use your radio, etc. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] u2_flash_tool : Can not find the command
3. Using sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w txrx.bin ¨Cw I'm a litttle concerned that you have an MMC card and not an SD card, based on the device name that gets created when you insert the card into your read/writer. Using SD cards, I've only ever seen Ubuntu generate devices of type '/dev/sdX'. No need to worry about this. The mmc driver handles both MMC and SD cards (their protocols are almost identical). The sd driver actually stands for SCSI disk; but in recent kernels, SATA and USB storage media also show up as sd devices. So if you access your SD card via a USB adapter, it becomes an sd device. If you access your SD card via a builtin non-USB SD interface, it becomes an mmcblk device. Ah! The issue is probably that he's accessing mmcblk0p1, that is, the first partition. I thought the USRP2 used unpartitioned cards, i.e. he should write to mmcblk0 (which will overwrite the partition label and eliminate those p1 devices on subsequent accesses anyway). John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboard
When we use any of the USRP daughterboard to transmit, do we need the authorization? For example, FRX900 includes the cell phone bands in US. If we use FRX900 to transmit, do we violate the FCC rule? Or, we could legally use any daughterboard on any band that falls in the frequency range of the daughterboard? When the OpenBTS folks transmit in the cellphone bands, such as at Burning Man last year, they get an STA (Special Temporary Authorization) from the FCC. They also get permission from the chief engineer of one of the incumbent cellular licensees in the area, to avoid interference with already-licensed traffic. I don't recommend proceeding without those precautions. I believe no license is needed to do bench testing with a dummy load that doesn't radiate beyond the tabletop. Merely opening the metal cover of your PC probably causes more electromagnetic radiation than that. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: SanDisk cards flakey?
Or maybe I have to try to use another brand SD card rather than Sandisk? It's possible you need to use another brand card, as these seem to be notoriously flaky. SanDisk SD cards are not notoriously flaky. They invented the SD Card format and are, I believe, the largest maker of Flash devices in the world. They're the gold standard for SD cards (and their Extreme line is the gold standard for endurance, surviving in cameras destroyed by flying debris, dropped from balloons at tens of thousands of feet, etc). If the USRP2 is notoriously flaky with SanDisk SD cards, there's almost certainly something wrong with the USRP2's implementation of the SD card interface -- not with SanDisk cards. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSM Handset Emulation
Now that there is a functional basestation available for GSM, I was wondering if anyone is trying to build software for a GSM handset. This way, I could use my laptop (e.g. in a manner similar to skype) to talk with folks when I don't have a GSM phone handy. It wouldn't be very convenient, since you'd have to have a USRP, plus antennas, dangling off your laptop. GSM handset software could probably use a lot of the existing low and medium level GSM basestation code. Having free implementations of both sides of the interface would make debugging easier, too. But there'd still be a lot of work involved. You'll need a SIM card and some way to read it, too. Sounds like a fun grad-student project to me. You could skip a lot of hassle with codecs and audio I/O and such by first making something that would offer data service (e.g. SMS text messages, or Internet access) by talking to a GSM basestation. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] reducing the latency in tunnel.py
Another study you could look at is ftp://ftp.cs.washington.edu/tr/2009/10/UW-CSE-09-10-02.PDF It gives another overview of where latency comes from, and shows how you can get around some of it. We were able to get turnaround times for our application below 300 us by making a few simple modifications to the GNU Radio C++ code. Nice work! Have these modifications been accepted upstream? It would be great if your RFID reader was a standard part of GNU Radio -- I suspect that a lot more experimenters would start messing with RFID. And it would be even better if every interactive GNU Radio application could benefit from the latency improvements you made. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem of making a call
I would like to make a call between two mobile phones using OpenBTS, but the call exit after the phone begin to ring, message is show below: Could anybody help me with this problem?* I had the same problem at Burning Man with my phone (a BlackBerry). Some phones seem able to make voice calls, others suffer some kind of protocol violation that makes them instantly hang up. We never succeeded in debugging the problem there. I suggest trying some other phones -- if you can get one that works, you can compare the protocol traces to one that fails, and see if you can figure out why. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Max temperature for usrp2
few things come to mind: the SD card (one of the cheaper components, I suspect), the ethernet cable, and the resistors. You could try using a SanDisk Extreme III SD card. They're engineered for rough environments; their web site has photos recovered from one that went up for days in an untethered weather balloon and was then recovered from the ocean. Another (CF card in that case) was found in the remains of a news camera that was too close to a controlled demolition of a bridge. Some great shots of flying debris heading straight for the camera! (Can't find that URL just now...) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sound input using mic / line in problem
gr-audio-oss and gr-audio-jack. The sound module being used is snd_hda_intel. In my experience, there seem to be endless permutations of problems with snd_hda_intel (HD Audio). Even in newer Linux releases like Ubuntu 9.04. I don't think I have a single machine on which snd_hda_intel is trouble-free -- including an HP Athlon64 desktop, a Dell Atom netbook, and an Acer Atom netbook. (which may or may not have anything to do with your problem.) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] LW/AM/SW radio very cheap in laptop?
There's another chance to get kids into radio... If a high volume kids' laptop had stereo HD audio ports available (24-bit 192 kHz converters, 95 db input and 100 db output), how cheap and small a circuit could you build onto that motherboard to provide useful LW/AM radio reception? Could you use the left output channel to tune, the right output channel to control the gain, and feed the resulting filtered signal to a pair of input channels? John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OpenBTS Technical Report
I am looking for the openBTS webpage that had the technical details of the 2008 burning man experiment on them. Things like: - 7 simultaneous phone calls at 50% CPU - imsi filtering when they first started up http://www.kestrelsp.com/OpenBTS.html http://www.kestrelsp.com/FieldTest/index.html An evolved derivative of the OpenBTS code that was tested at Burning Man last year has been given to the Free Software Foundation, released under GPLv3. It is now checked-in to the GNU Radio source control system, and is publicly available. (Due to an over-cautious order in a pending court case, the authors can't point people at public sites where it can be downloaded anonymously, but anyone else can do so.) I haven't seen this code appear in a GNU Radio release candidate yet, but I hope it will soon appear in one. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Python 2.6 and Python 3.0
Instead, python3 is included in both 8.10 and 9.04. Is the plan to port gnuradio to python3? There's no plan yet. This needs to be investigated. Fedora 10 is 2.5.2. Not sure what they are planning. Anyone know of a mainstream distro that uses python 2.6? Python 2.6 missed the release window for F10. Fedora 11 plans to make Python 2.6 the default (Fedora is about pushing the boundaries, and having Python 2.6 as a transitional release on the path to Python 3000 is no exception.) The F11 Roadmap says they're 85% done so far (and have no fallback position, i.e. it's gonna happen even if some things break around the edges): https://fedoraproject.org/wiki/Releases/11/FeatureList https://fedoraproject.org/wiki/Features/Python_2.6 The F11 alpha is already frozen, it'll come out on Feb 5th. Feature freeze is March 3. Beta code and string freezes are March 10. Is there any chance that a GNU Radio release with Python 2.6 support is going to hit those dates? Python 3.x is going to be a much bigger deal for GNU Radio -- but 2.6 is designed as a compatible transition release so you can evolve your code forward, gradually. Guido van van Rossum's slides on Python 3000 and You are at the first URL below: http://www.artima.com/weblogs/viewpost.jsp?thread=227041 http://www.python.org/doc/2.6/whatsnew/2.6.html http://python.org/download/releases/3.0/ John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Deutsch/German podcast about DSP, GNU Radio, and USRP
Harald Welte was recently interviewed on Chaosradio Express (by Tim Pritlove) about DSP, GNU Radio, and the USRPs -- for two hours! The interview is in the German language. http://chaosradio.ccc.de/cre087.html The MP3 file (118MB) can be streamed or downloaded here: http://chaosradio.ccc.de/archive/chaosradio_express_087.mp3 John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Prototype Hardware for gnuradio
nexsdr_source_c() block patterned after usrp_source_c(). Converted version of usrp_wfm_rcv.py. Converted version of usrp_nbfm_rcv.py. Congratulations on building your own high function SDR hardware! Just a brief remark on the software. It's great that you were able to get it running quickly via replacing usrp with nexsdr in various places, but that really shouldn't be necessary. The fm radio high level GUI and signal processing code should not know or care what low-level radio interface is in use. The WBFM application required removal of the subdevice code, modification of the tuning code (removed the residual tuning), and adjustment of the gain. The prevalence of the USRP1 led us to be lazy about how GNU Radio applications are structured. High-level code like usrp_wfm_rvc.py have the name and details of the low-level radio interface (usrp, subdevice names like usrp_dbid.TV_RX_REV_3, etc) wired into them. Now that we have USRP1, USRP2, HPSDR, and your new SDRtrack, this is becoming more than inconvenient. All the low level drivers implement the same interface class -- the rest of the code just needs to know which one to call, dynamically. The high level GNU Radio software should be altered to receive from standard radio input and transmit to standard radio output, so that every application doesn't need to be tweaked just to change the device used. The standard radio input would be set in a tiny config file (probably just a Python source file, unless the all-in-C++ faction wants to provide a parser), kept in your $HOME directory. Then all the filenames wouldn't start with usrp, wouldn't need to import the usrp class, etc. They'd import a class like radio, the radio class would open the $HOME/.gnuradiorc file, and it would import the USRP, USRP2, or whatever other module the user had selected (manually, or in a small config GUI). This is how audio works, it's how video works, it's how disk drives are interfaced. You don't run sata_mount for your 1.5TB disk drive, pata_mount for your old 80 GB drive, and usb_mount for your flash keychain; you just call mount and it figures it out. Modularity is your friend. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using gnu-radio for ARM NEON
Do you mind adding NEON to this list? NEON is a SIMD unit on ARM Cortex-A8 processors. Information on NEON instructions is at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204h/Bcfjicf j.html. Sorry it si the superseded link, I'm too lazy to find the current one :) This assembler language manual gives pretty good details (except actual instruction encodings): http://infocenter.arm.com/help/topic/com.arm.doc.dui0204h/DUI0204H_rvct_assembler_guide.pdf I also tried looking at NEON for the ARM-9, but got: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409a/index.html Cortex-A9 NEON Media Processing Engine Technical Reference Manual Revision: r0p0 This is a placeholder for a restricted document that is not available from this site. Please contact ARM for more information. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using USRP/GNURADIO Commercially
You can charge any price you like, and you're only obligated to pass on the code to those you sold or gave the binaries to. Well, no. Once you ship a binary to even a single person (outside your company), that person is free under the GPL license to make and share as many copies of the binary as they like. Each eventual recipient has the right to come back to you to get the source code. Each binary must come with an offer that says how to get the matching source. Your recipients are free to reproduce that offer for their recipients. So, you are obligated to provide source code that matches each binary version that you ship, to *anyone* who has the binary (not just your own customers), for three years or the support lifetime of the binary product, whichever is longer, and for a low cost. See paragraph 6(b) of http://www.gnu.org/licenses/gpl.html . There's a FAQ on the GNU Public License at that same web page. But answer me this: Why did we (the gnuradio experts) select a license that does not provide a clear answer to Matt's question? I'm one of the originators of the GNU Radio project. We picked the GPL because it protects the freedom of the code (and the code's users), and encourages a community to form around the code. By then I'd already started and sold off one company that made tons of money by selling and supporting GPL-licensed and other free software. I really didn't see any problem with making commercial gear that used GNU Radio under the GPL. There are tons of network routers and PDAs and such that ship with GNU/Linux inside -- much of which is also GPL-licensed. Those companies seem to be able to read the license, figure it out, and make money. You can make money with free software by selling your expertise; by selling convenience; by selling support; by selling quality assurance; by selling documentation; by selling hardware that works with free software (like Ettus Research does); and in other ways. You just can't make money by preventing people from seeing your code, freely sharing your code, and improving it if they want to. When we started GNU Radio, the only working software-defined radio code was proprietary. The opportunity was there to build a community-maintained SDR code base, that everyone would be free to experiment with, share, improve, or commercialize. We did it (thanks, everybody)! Eric and I could've built another proprietary SDR package, but then you wouldn't all be here having this conversation. John (PS: Most of the proprietary software I've seen has even more draconian and unreadable licenses than the free software.) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UK shops track customers via GNU Radio monitoring their mobile phones!
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. 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 shopping centre. Bluewater, in Kent, said it had no plans to deploy the equipment. A spokesman for Gunwharf Quays was not available for comment. Owners of large buildings currently have to rely on
Re: [Discuss-gnuradio] AMSAT programming help needed
AMSAT (the Radio Amateur Satellite Corporation) is working with its partners on a Cubesat (4 inch cube satellite) to be launched in the next few months. We need experienced help programming an MPS-430 (TI Microcontroller). Is that the same as the MSP430 (see Wikipedia)? I see references to both. If you are a U.S. citizen (sorry, ITAR and out of my hands) and are interested in helping, please email me directly. Can you describe (or point to a URL for) the specific need for ITAR restrictions on this software? I looked, but found nothing on the AMSAT site. ITAR is never out of our hands. We beat these bastards on encryption, and we can beat them on satellites too. All it takes is a global, scientifically published, shared effort. There are Cubesat's being built all over the world. They don't follow US ITAR rules. The next rocket they'll launch on is in India. Clue? If you live outside the US, and you program this, AMSAT is free to use it. AMSAT is free to import code. This is a large part of how we beat the bastards. We just stopped writing crypto code in the US, or buying crypto code from US companies. We started contracting with foreigners. ITAR prohibited us from teaching them to write it, but they could learn to write it themselves, and we could pay them to import the results. (And they were free to ship the code to any other country in the world -- unlike us.) Smart people among the billions of non-US citizens figured out for themselves that they could learn to write it (whether or not we paid them). The center of crypto software development moved outside the US. Which is exactly what the ITAR rules were trying to prevent. E.g. Europeans designed a better replacement for DES, which became AES in a fair, global competition. Eventually even the thick heads among the spooks got the message, and the crypto export rules changed. The sooner we have MPS-430 Cubesat software that's built in a free country, available to any space experimenter worldwide, published under a free license, the sooner we'll all have access to space. John Gilmore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OLPC - next generation with SDR?
As preface, I'm not a radio engineer. I'm a software guy with pretentions to understanding digital hardware. I have a few signal processing books on a dusty shelf. You lose me as soon as you start talking Q signals. The Odyssey board operates at 10MHz IF; so wouldn't it need an external tuner? I am in agreement with Frank that we can currently do it for a few tens of dollars ~$50 in small quantities and that include parts and boards. We can even put together a prototype which will allow HF shortwave reception from low bands through about 21 Mhz covering these bands: [15m thru 120m] What kind of antenna would this require? Something external to the laptop? Or something that could be built into the plastic case? The dsPIC33 has more than enough horsepower to provide good (synchronous) detected AM and even some modest AGC. We won't need a processor; the laptop will come with a processor much faster than 40 MIPS. (The current XO CPU is a Geode LX 433 MHz x86, with MMX, 3DNow, and some SSE instructions.) We need a DDS and a QSD (we do not need the QSE for the receive only version) if we are going to tune the HF shortwave broadcast bands and get reasonable performance at low cost. I think that single chips are available that do broadcast-band AM and FM decoding for cheap; has nobody done this for the television and shortwave bands? Or is the problem that nobody's done this digitally? If we can provide something that gives real benefit for the target kids, we shouldn't be dogmatic about analog versus digital. Alternatively, if OLPC provided a million-unit order for a digital tuner chip that would target all these bands, others could then buy the cheap chip for a variety of projects. This would provide a clear example of how it could be done. It does not meet the price point, but it shows the capabilities and then we can negotiate. I'm glad you-all are pointing out low volume prototypes. I hope we'll get someone interested who has designed high volume digital radio electronics. High volume ~= million-unit. (Do any people like this exist? Perhaps Matt's bluetooth design has shipped in that quantity; WiFi does too.) There's already an entire high speed digital radio transceiver in the existing XO: it's the Marvell Libertas WiFi 88W8388 controller chip and 88W8015 radio chip. It's reprogrammable, though the ARM code that runs in it isn't open source yet (the high level code can be open sourced, but it runs on a proprietary RTOS). I think the best strategy for a $50 laptop's radio would be to have either an internal antenna or a single connector; a small number of cheap analog components; perhaps *one* analog/digital chip (multi channel DAC/ADC radio chip); and stuff *everything* else into a corner of the digital system-on-chip that implements the rest of the laptop. It's hard to prototype such a thing, though perhaps using an FPGA that come with a fast embedded MIPS or ARM CPU would be the closest. The current XO uses two custom chips (the DCON display controller, and the CAFE camera/flash/SD controller), some very custom mesh firmware for the ARM core inside the WiFi chip, and some very custom firmware for the EC embedded controller battery charger chip. A $50 laptop version would probably mash all these chips together with the CPU, GPU, and its southbridge support chip, leaving only one system-on-chip, plus flash, DRAM, a few external analog chips, and a pile of analog electronics for power supply and such. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OLPC - next generation with SDR?
The thing does appear to have sufficient horsepower to do some DSP. I would like to think we can make several things available to this project. For example, I think a tunable HF receiver for shortwave AM broadcast is easiy achievable for very modest cost. Further out, I would to see the use of this machine and OFDM skywave to provide WAN capability to large areas of the world without such capability. If we were given a square inch of circuit board space, twenty cents for components and wires and connectors, four pins, 0.2 watts of power when operating, and half a million gates colocated with the CPU and memory bus, what radio capabilities could we offer to the next generation OLPC project? That's the fun challenge. Here's some background. The reason software radio hardware has always cost so much is that it ships in low volumes. The oscilloscope boards we started with were $1400. The USRP is many hundreds, and the USRP-2 will be more. But if the USRP's RF I/O capability was integrated onto a high volume motherboard, it would cost a lot less -- maybe $50 or $25. If it was integrated into a chipset, even cheaper. Similar but specialized wireless capabilities are in USB wifi dongles that *retail* for $40. Today's children's XO laptop is just the first in a series of high volume, low cost laptops -- from a variety of vendors. We can assume that with each generation they will get faster, lower power, and cheaper -- as we learn more about how to design and build in that problem space. (Until Dec 31, you can buy one for $400 -- and a second one will go free to a kid in a developing country. After that, they won't be sold at retail. See http://laptopgiving.org.) For the next generation effort, if they have the design time, they are likely to build a big custom chip that integrates a whole CPU, and a pile of system and peripheral circuitry. Their stretch goal is a $50/ea laptop for kids, one that's much better than the current $200 one. We know they will want 2-channel sound in and out. They have already jiggered their current hardware so that the audio biases and filters can be switched out of the circuit, so that ordinary low voltage sources and sensors can be plugged into the audio port and used to sample real-world sensors. They have full control of the drivers, since they're basing the whole thing on Linux, and they have real kernel hackers and real GUI hackers and such. Their system already uses wireless WiFi, so it has antennas, and they've done a detailed radio analysis of the package and design. The difference between this design effort and the other things the GNU Radio crew has done is that the result has to cost only incremental pennies, cost zero power when not running, and run on batteries when running. On the other hand, gates and connectors and small antennas come almost free (they're making hard-tooled plastic molds anyway; adding a connector or other wires is simple). Assuming their basic design provided roughly their current sound and analog input capabilities, what could we recommend that they do in order to make the platform much more capable for SDR? My first thought is to just increase the sample rate and effective bits per sample of the audio processing hardware, and increase the number of channels so that ordinary stereo audio can happen simultaneously with analog I/O. I think it's a crime that cheap analog I/O chips top out at 200 kilosamples per second. Even making it able to receive AM-band and below, by plugging in a wire of appropriate length as antenna, would provide years of experimentation in the schools. Should the analog circuitry be wired up to the existing cat ear antennas on the laptop (which are currently only used by the WiFi chip)? The analog circuitry would need to be switchable for use in three domains: audio (speaker/mic), DC analog (sensors), and radio analog (SDR). Could we make it usefully transmit? Many of Matt's transceiver daughterboard designs are very similar -- with only a few components changed to set the frequency range. If made in high volumes on an existing board, what would the cost come down to? Could we shrink a single band transceiver into the above constraint? Could we design a cheap multi-band transceiver that lets these components be switched under software control? Can the CPU and the free signal processing gates automatically measure and compensate for cheap (signal-distorting) analog circuitry? What kind of signal processing math hardware should we add to the custom chip, assuming that the CPU itself would be low power/low heat/low performance for its time? Should this be a CPU math accelerator, or should it be wired to the digitization hardware? Should it do one thing well (if so, what?) or be more general like traditional x86/PPC/etc DSP instruction sets? Should we suggest making some of our gates of the custom chip into a field programmable gate array, reconfigurable in software? If so, what would we
Re: [Discuss-gnuradio] Soft-DVB working flawlessly
Soft-DVB working flawlessly ... thanks again for precious help, Thank *you* for building a great tool on top of all the signal processing work that's been poured into GNU Radio over the years. We hoped someone like you would do things like this! I'll love to see it GUI'd and packaged so that anybody can make a local DVB transmission station by just plugging the hardware together, installing the right software package, and feeding it realtime video streams. Has anyone glued GRC into MythTV? I can already think of one use that others can make of your transmitter. EFF and I are interested in measuring the DRM responses of various digital television consumer products. DRM is the unnecessary restrictions that are built in to control what consumers can do. (Like no fast forwarding; won't play in some countries; or only works with one manufacturer's products.) DVB is really thick with complicated, ugly restrictions like can only record one copy -- only on Tuesdays and only within 1000 meters or with members of your immediate family except for kids of divorced parents. I bet there is a lot of variation in the products that try to enforce it -- and maybe some don't even try. Manufacturers tend to avoid documenting these 'features', for some reason. We consumers can benefit by collectively reverse-engineering what they are up to. In particular, nobody should be buying DRM-laced products without knowing it, when similar non-DRM products would serve the consumer as well or better. But how can we tell them apart? A broadcast-quality software transmitter for DVB (and for ATSC and other dtv waveforms) would let us do these tests. (We'll also need a simple editor for MPEG transport streams, for inserting and removing Broadcast Flags and other data items.) John Gilmore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PS3 versus freedom
If you want to run on the PS3, you're most likely going to want the IBM SDK 3.0. The SDK really, really wants FC 7 on the PS3. Some people will do anything for crunchons -- or promised future crunchons. (A crunchon is a unit of number-crunching.) I was wondering why this SDK wasn't already part of the SuSe or FC7 releases. Ten minutes of research later, the answer is: it's proprietary. Why would anyone on this mailing list want to install proprietary compilers? The IBM license agreement is extortionate. Besides the usual rape and pillage, it says that: http://www14.software.ibm.com/cgi-bin/weblap/lap.pl?la_formnum=li_formnum=L-MCHN-6MVMPVtitle=XL%20C/C%2B%2B%20Alpha%20Edition%20for%20Cell%20Processor * You are not authorized to use the Program for productive purposes * THE PROGRAM MAY CONTAIN A DISABLING DEVICE THAT WILL PREVENT IT FROM BEING USED AFTER THE EVALUATION PERIOD ENDS. YOU MAY NOT TAMPER WITH THIS DISABLING DEVICE OR THE PROGRAM. YOU SHOULD TAKE PRECAUTIONS TO AVOID ANY LOSS OF DATA THAT MIGHT RESULT WHEN THE PROGRAM CAN NO LONGER BE USED. * You assign to IBM all right, title, and interest (including ownership of copyright) in any data, suggestions, or written materials that 1) are related to the Program and 2) You provide to IBM. * Your right to run the program ends after 90 days. [I hope Eric hasn't provided IBM a copy of the GNU Radio code that compiles under this compiler: IBM will end up owning the copyright on GNU Radio. This may occur even if Eric just posts the code in a public place where IBM can download it.] If the above wasn't enough, it's also against GNU project policy to use the mailing list or project documentation to advertise or advocate for proprietary software. If the GNU compilers for the CELL aren't good enough for us, I suggest that we improve them. If we just can't exploit the CELL processor without proprietary software and patented algorithms, then I suggest we go back to focusing on hosting GNU Radio on hardware that comes with freedom. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Deeper story on FCC versus open source SDR
http://news.com.com/Feds+snub+open+source+for+smart+radios/2100-1041_3-6195102.html This story had more details and investigation than the others I'd seen. FYI. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Nerd Salon 7/10 in SF, featuring Matt Ettus
Date: Tue, 03 Jul 2007 14:19:53 -0700 From: Annalee Newitz [EMAIL PROTECTED] Subject: Reminder: Nerd Salon 7/10 Nerd Salon returns in just one week! Bring your friends and robots and alien lovers! Here are the details: WHEN: Tuesday, July 10, 2007, 6 PM - 9:30 PM WHERE: 111 Minna Gallery, San Francisco (111 Minna St.) You've heard about it . . . You've yearned for it . . . At last, on July 10, it's another crazy night of Nerd Salon! Come out and socialize with your fellow geeks in a mildly intoxicated manner! This episode of Nerd Salon brings you: * The circuit board stylings of Matt Ettus (www.ettus.com), who will be doing a live demo of GNU Radio, the open source software-defined radio project (www.gnu.org/software/gnuradio) * A mind-bending puzzle for you to solve for a very special prize. This irregular evening of mayhem is organized by your nerd captains Jennifer Granick (www.granick.com) and Annalee Newitz (www.annaleenewitz.com). Come out and have a drink with people who won't make fun of you for hacking, hating on DRM, copyfighting, discursing on public policy, building nuclear reactors in your garage, reading science fiction, working in a bookstore, arguing about open source software, collecting Buffy dolls, dancing with robots, blogging and/or podcasting, lusting after the iPhone, or getting excited about the new Hulk comic book. URL: http://upcoming.yahoo.com/event/209727 -- Annalee Newitz writer: science, technology, pop culture, sex http://www.techsploitation.com/ * president: computer professionals for social responsibility http://www.cpsr.org * editor: other http://www.othermag.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and USB full speed (1.1) transmit
Well, it looks like data is coming out, but it looks like I get 64 bytes out, then there is a hiccup about 5 microseconds long. I am getting suspicious the OSK doesn't get the data on the USB bus fast enough. What is the source of the data you're transferring over the bus? If it is coming faster than USB1.1 can handle, of course you'll see hiccups where data is dropped. (The USB2 firmware/fpga sets a flag that the software can read when this happens -- that's what produces those U dribbles on the terminal sometimes.) I think there's a way to select a counter in the FPGA that just transfers an incrementing number in each outgoing USB packet. (Perhaps it's a different FPGA load instead of a settable flag in the main version.) This was used to debug similar issues between the FPGA and the FX2, and between the FX2 and the software library. Alternatively, you can decimate the source down to a very low data rate, so it won't overflow. Get the rate as low as you possibly can, for debugging. (Or, if there's a demodulator in the FPGA, you could e.g. have it tune an FM radio station, demodulate it on-chip, and transfer only the audio over the USB bus, which would be well within its available bandwidth. But I don't think anybody has coded that FPGA transform... yet.) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Avoiding plug-n-fry design
It's beginning to look like future daughterboards should include an attenuator or fuse or something. This would avoid the idiotic result that you plug 'transmit' into 'receive', as any sane computer-oriented person would do, and (invisibly) fry your board. Having the same connector on the tx and rx ports makes it that much more likely to happen. (I'm not arguing that we should enter connector hell by making them different!) Prominently selling a loopback cable that includes an appropriate attenuator would also be a positive step. Perhaps each amplified transmiter should come with one, in a nice ethernet-orange color. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB speed data point
I think the limitation is on the 8051 end. One 512-byte packet takes 8.53 microseconds to cross the USB channel, and the 35.7 MByte/sec sustained rate implies the 8051 sets up the next packet in only 5.81 microseconds. I don't think there is any pipelining at this level. You're probably right. It's known that the SSRP (which had no FPGA, just a USB interface and an ADC) got higher thruput, because it programmed the USB interface registers to automatically stream data through without the intervention of the 8051. (It knew all the traffic was inbound, so didn't need the option to switch directions on the bus.) We could get a similar speedup in the USRP (or LLRF) by having the 8051 jump to different inner loops when doing input-only, output-only, or both input and output over the USB bus. Think of it as hoisting one of the invariant decisions out of the inner loop. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Announcing GNU Radio Release 3.0
Once the signed binaries are on the GNU mirrors, should an announcement email go out to the info-gnu@gnu.org mailing list? Significant releases, like an X.0 release, should probably be announced there. Such a message should have a lot more about what GNU radio is capable of, what it does well, and a lot less detail than the version that went to our own hackers. Plus describe the big changes since the 2.0 release...some time ago. It'll be read mostly by people who don't use GNU Radio yet, but who might want to know when to use it, sooner or later. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] to prevent mental damages, avoid dB's.
transmit power converted to dBm (1 dBm == 1 mW) minus the attenuator loss = output power in dBm. E.g. 100 mW - 20dBm 20dBm - 15 db att = 5 dBm 5 dBm - 3.2 mW Actually, I think 0 dBm = 1 mW. dB's are a royal pain in the butt. They eluded me for years because they required a lot of rote memorization and made no sense. For those of us not pickled in radio-speak from an early age, but who know basic algebra, there's a simple way to deal. Ignore deciBels. Use Bels. Bels are easy and obvious. They're a straight logarithmic scale in Base 10. 100 mW is 2 Bm. 10 mW is 1 Bm. 1 mW is 0 Bm. 0.1 mW is -1 Bm. DeciBels are just tenths of a bel. So if you shift the decimal point one place, you're suddenly calculating in an easy to use notation. Here's the above calculation in Bels: 100 mW - 2 Bm 2 Bm - 1.5 B att = 0.5 Bm 0.5 Bm - 10 to the 0.5 power - the square root of 10 - about 3.2 mW See, now you not only know the answer, but you know WHY 5dBm is 3.2 mW. Why the EE universe settled on doing everything in tenths of a logarithmic unit is way beyond me. It's as if every carpenter figured every length in deciInches or decimeters, even if inches, kilometers or meters would be the more straightforward unit. How often do you calculate in decivolts, deciwatts, or decimeters per second per second? The rumor is that decibels were invented because somebody at Bell Labs couldn't cope with decimal points or negative numbers, in the days when equipment wasn't capable of dealing with large orders of magnitude (e.g. the painful-to-someone 0.3 Bel became the friendly-to-someone 3 deciBel). Of course, now that people regularly see 5 to 10 orders of magnitude (5 to 10 Bels) (50 to 100 deciBels) (factors of 1 to 10 billion) in ratios, such as in radar, digital signal processing, or fiber optics, the deci has just become a hindrance. You can do your part to clear up this idiocy by using Bels in most places where the lemmings use deciBels. You may actually get them to think (briefly). John PS: Don't even get me started about why dBm's aren't referenced to watts rather than milliwatts! Since a milli is 1/1000th and that's just 3 orders of magnitude, referencing to ordinary watts would merely involve subtracting 3 or 30 from the number, e.g. 40 dBm = 4 Bm = 1 BW = 10 dBW. It reminds me of how we're still calculating speeds in 5280-foot units per 3600-second units rather than in some sane system using basic decimal units. Actually using BW notation in your thinking and writing may overload lemming brains, though. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB2, 32 MByte/s or 480MBit/s?
David Carr said: As a point of reference the SSRP was used in a radio astronomy application where maximum bandwidth was important and we were able to squeeze a little more than 40MB/s out of the bus. I think this says that there is a little more to be had but that the USRP is doing a pretty good job at 32MB/s... The SSRP and the USRP both use the same interface chip, but they run it in different modes. The SSRP doesn't support transmission, so it uses a fully-automated hardware mode. The USRP needs data to go both ways, so there are some firmware delays in the 8-bit processor that runs in the interface chip. If someone cared, it is probably possible to reprogram the firmware so that when no data is being transmitted, the automatic hardware mode is used. The firmware would have to know, or be told, when to switch in and out of this mode. But this would gain 25% more bandwidth! (A similar optimization could be done for transmit-only applications. It's mixed transmitting and receiving that takes more overhead. Also, few people have looked at that firmware code; it may be possible to optimize it further in other ways.) Making this change might also require changing the Verilog code in the FPGA, if the signals that it uses to communicate with the USB chip today aren't compatible with the fully automated hardware mode. If you're lucky, Matt and Eric already thought of that :-) while debugging the USB interface, which was a hairy process due to undocumented bugs in the USB chip. John PS: Hacking in similar places would also allow the USRP to run on USB 1.1 at 12 megabits/sec, for low sample rate applications. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SDR Design Competition
There are monetary prizes... Yeah -- unspecified ones! It looks like an incredible amount of work, under really picky and idiotic rules, solving problems so challenging that there *isn't* any commercial gear that does it, at any price. For an unknown and probably tiny reward. And to hand it all over to somebody else to own!!! (They won't accept work that has been released under a public license, such as the GPL or even the BSD license. If you spend two years writing this stuff, they will *own* it at the end, and you won't even be able to keep working with or evolving your own software or hardware. And you won't be paid for any of this.) They've issued a call for suckers. Any takers? [Now let's go back to improving the world with GNU Radio...] John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] The last LORAN C receiver: SDR
http://phk.freebsd.dk/loran-c/ Seems like a natural hack for the USRP. He (Poul-Henning Kamp) had to use a PCI card at the time (2003). He claims it's un-jammable and similar in resolution to GPS; see the LORAN-C politics section. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Modem and/or ADSL Daughter card
It shouldn't be too difficult to design a daughter board for the USRP to sample phone line voltage (with an appropriate line interface circuit of course). After that it should be rather easy in GNURadio to generate DTMF tones for dialing, and modem tones for data communication. DSL is a good example -- it would be great for students, technicians, and researchers to be able to study the performance of DSL modulation techniques, and try making improvements. You can probably add a telco block to the low frequency tx and rx boards without trouble. Don't forget to support voice communication as well as DSL and modem! (Hmm, anyone want to reimplement the Telebit modem for fun? It did half-duplex communication on hundreds of ~2-bit-per-second carriers, avoiding the frequencies that didn't get through cleanly on your particular phone network, and flipping back and forth from TX to RX many times a second. There's probably an acronym for it now.) Hacking up an interface and code for 10 megabit Ethernet on coaxial cables would be fun too. That could be done on standard TX and RX boards, probably by just wiring them to the transceiver cable of an Ethernet transceiver. Ethernet modulation is pretty straightforward. For true incestuous pleasure, we could code up the signal modulation and electrical interface for USB 1.1. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TX/RX simultaneously using one USRP board
Just curious, why did you first fm_demod and then fm_mod. You could also do: src = usrp.source_c (0, rx_decim) dst = usrp.sink_c (0, tx_interp) if_filter=gr_fir_filter_ccf(1, if_filter_coeffs) self.connect (src, if_filter, dst) By adding a few blocks to the FPGA (like the FIR filter and a feedback buffer), the implementation could avoid pushing these samples across the USB entirely, without any changes to the Python code! [This will become much more useful in later USRPs that have bigger FPGAs. You could pull out a few received signals, e.g. two or three FM transmissions out of a wide band, translate each to a different frequency, mix the results together and feed it out the transmit path, all on the USRP. While simultaneously having some control channels that run across the USB to be processed by host system software. Sounds like a great design for a cellular radio base station.] John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Capturing data to file
It seems there is something wrong with the way that mux is declared in the capture_to_file.py code (0xf0f0f0f0). The problem is that Python promotes that value to a bignum because it doesn't fit into an int (as a positive number). This was a recent change to Python, which is great for numeric users but has caused small problems for people making bitmasks. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_* gains on Mac OS X much greater than on Linux
It should be pretty simple for the USRP's FPGA to swap the bytes of 16-bit samples it delivers in USB packets, if instructed in a control register by the host. This would avoid any speed penalty for big-endian hosts. (It's also pretty simple to determine that a simple byte-swap would be a complete cure for the problem, by temporarily doing the swap in software.) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sparc -- x86 data exchange
Three opinions... * GNU Radio should be processing data in the local machine's native byte order and data format (e.g. IEEE float). You should have to explicitly tell it to do something about byte order (e.g. convert samples to little-endian). * Any conversions we offer should say nothing about machine types (x86), rather should be specific about byte orders. E.g. we should not offer convert longs from x86 to sparc, we should offer output big-endian longs and input big-endian longs. These conversions would be implemented on all machine types, but of course on some of them there's no work to do. An extra name for big-endian should be in network byte order, for people who are squirting partially-processed data over the net to another signal processing program on an arbitrary machine. (My opinions on byte order come from having co-designed and maintained the BFD library that the GNU binutils use to read and write object files, which require pervasive and specific attention to byte order. We changed our byte-order API several times until we got it right and easy to use.) * I'm hesitant to make GNU Radio depend on Yet Another random library package like liboil. Building it is already an exercise in frustration, as is trying to package it for a distribution. Can't we skip some premature optimization and get back to making the program do real things that real people want to do? I don't see the obvious GUI-operable scanners, recorders, radar screens, etc, that our capabilities are supposed to make it easy to create. We're how many years into this package?, and still re-re-rewriting the guts. Let's rather make it something that tens of thousands of people would use to record multiple FM stations, or scan and log police and ambulance frequencies, or TiVo the ham bands, or avoid DRM on over-the-air TV transmissions. Even our FM decoding is inferior to what cheap transistor radios do. Six months' focus on polish and applications would make a world of difference. Just my 2c... John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Groklaw and Dr. Frank Brickle discuss SDR
Groklaw.net is an interesting blog by Pamela Jones, paralegal of mystery, who has entertainingly coordinated the free software community's response to the SCO v. IBM lawsuit. Once in a while the lawsuit gets slow and she has time to cover other things -- like Katrina, FEMA, and emergency communications. Frank talks about how he was approached by FEMA to help make DttSP and the SDR-1000 usable by FEMA and other first responders to patch together their lockdown government-contractor radio systems: http://www.groklaw.net/article.php?story=20050916105216639 Many comments by readers are interesting, too. Frank's comments were based on this earlier posting by Pamela about how using open standards makes systems much more likely to work in emergencies: http://www.groklaw.net/article.php?story=2005091305273070 John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gigabit Design Proposal
A critical parameter will be the response time (latency) required on the host. This is largely controlled by the amount of bufferring on the GITD. Pushing in the opposite design direction is the desire to minimize latency and cost on the GITD itself. A memory-mapped interface is great for software but adds to the complexity and bus bandwidth requirements when designing for hardware. The memory bus has to handle simultaneous packet reads writes, etc. It would be a very much simpler design if it had only a single packet buffer for xmit (and another for rcv). Everything would be serial (FIFO) rather than random access, and the data would just flow thru. The catch is that when the last sample of a packet was sent to the DAC, the host would have a very short time in which to send the next packet containing the next sample. Adding a simple FIFO on the DAC side barely increases the complexity but lowers the required latency (adding sampleperiod x fifosize nanoseconds of latency). This is the approach taken on the USRP, as I understand it. If the Ethernet core can steer each received packet into an appropriate fifo (based on its UDP port number, for example) then multiple DACs, ADCs, up- or down-converters can be accommodated. (Even if this set of FIFOs ends up implemented with an external RAM, it maybe best to conceptualize it as FIFOs rather than random access memory. A better FPGA or tighter latency spec could result in sucking that function entirely into the FPGA.) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
involve an application layer connection control scheme. For TX, each packet has a number and the device NACKs a packet if it is received when the buffer is full. The host then retries NACKed packets at a given interval and gives up if not successful after N tries. This is still a lot lighter than a TCP stack (and could be done in an FPGA). You've just reinvented the first ten instructions of TCP packet processing. The kernel code already does (roughly) that. What is also there in TCP is code to handle the case when that fast path fails (e.g. when a packet was garbled on the wire and you instead receive the next packet, and you buffer it and keep looking for that first packet to be retransmitted, but meanwhile more later packets are coming in, but you aren't out of buffer space yet, or maybe you are, and the radio transmitter is getting close to needing that missing data, or maybe it isn't, etc). I've been designing protocols like this since 1979 (PCNet). It's real work. TCP was designed on the back of an envelope, but it was designed by guys who had lived under NCP (its predecessor) for a decade, and had watched it go into catastrophic network-wide failure under overload. They threw it away, discarded its most basic assumption (guaranteed delivery of data by the network), and started over with the assumption that the network could throw away your data at any time (the endpoints need to be responsible for guaranteed delivery). Their second effort, TCP, has scaled up to billions of users and trillions of bits per second. But it took them many months to get TCP working, and many years of research and tuning to make it deliver reasonable bandwidth in the face of bandwidth limits (congestion). Bandwidth limits are why we are even considering replacing our current simple USB2 protocol. Our next interface and protocol WILL be sampling signals that are at the hairy edge of what the hardware and software can handle -- just like today. Our appetites grow over time. Our flow control protocol will work better if it's been modeled and implemented and studied and deployed and fixed by thousands of other people, in real world use. Maybe we should table this discussion until someone actually proposes to build a fast AtoD with an ethernet interface. I reopened it so the last word wouldn't be Don't ever do that. When someone eventually does it, I think we'll learn a lot from the experience. Maybe what we'll learn is Don't do that, but I think it will be a much more subtle and interesting answer (which will then help us scale to the next level of bandwidth, 10-gigabit Ethernet, InfernoWire, USB17, or whatever). John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gig-E alternatives dual USB2
The other thought is that if you are considering putting the peripheral remotely close to an outdoor antenna, perhaps an optical fiber solution would be better - why risk frying your CPU or your body? Copper GigE is sufficiently cheap and ubiquitous that a DAC/ADC board should use it. But for the people who want to mount the whole thing on a tower and run a nonconducting fiber back to their processing shack, a converter from copper GigE to fiber GigE is small, low power, and only costs a few hundred dollars. Though GigE sounds like a good idea to pursue, has anyone thought about using 2 or more USB 2 interfaces as an alternative? A good hack! I don't know if common multi-USB2 host interfaces can run all the ports at top speed simultaneously. Some look to software like a single interface connected to a hub. I wonder if we could make a Second USB2 daughtercard that would use some of the FPGA's digital I/O pins to drive another USB2 chip? (The protocol over the USB would need to change to add packet numbers, or to otherwise provide for a way to synchronize the two streams; but this is probably a simpler change than making a GigE interface.) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tempest for LCD displays?
I'm actually interested in detecting LCD and CRT leakage, and decoding the picture display from both LCDs and CRTs with a remote USRP, as a useful hack for determining what TV channels people are watching nearby (I know you can also listen for the local oscillator in the tuner, but the tube probably leaks more energy, and gives you more information. Ross Anderson and Markus Kuhn did some work on this. In fact, they designed a font that makes it hard to see the text on a computer screen when monitoring via Tempest emissions. And they have a great way of optical eavesdropping, based on watching a CRT's phosphor light vary over small increments of time (e.g. watching a wall that the CRT is illuminating). The USRP may be fast enough to capture such light from slow monitors, though the USB bottleneck gets in the way. See: http://www.cl.cam.ac.uk/Research/Security/tamper/ John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VGA-based DVB-T modulator
Does anyone here know if the VGA cards prevent you from controlling the DAC durinng the blanking intervals? Are the blanking intervals implemented in hardware or in software? Generally, video cards stop squirting bits during the blanking intervals, which are implemented in software. This lets the adjacent rows of the frame buffer be next to each other in the memory that the video hardware is scanning its way through. However, the timing of the blanking intervals can be controlled with a fair bit of detail. These are those terrible X config modeline values that can blow up your monitor if you set them wrongly. There will be *some* blanking interval, but it can perhaps be very short and can perhaps occur at an interval that won't often affect your signal. It would be great if video hardware had a mode that turned off this foolishness and just kept scanning out a section of RAM, raw. This would even improve refresh rates on things like LCDs that don't have to move an electron beam back across the screen during the horizontal retrace time. But few video chips probably do. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DSP based SDR
Have you considered putting a USRP-compatible daughterboard connector on your DSP-based board? That would let you mostly ignore radio front ends. You and anyone else could piggyback on the work done to make each radio front end receiver board made for the USRP. You'd just use the cheap connector/transformer board for direct connection to external radios. It seems like building the radio front ends is a significant pain (they're coming out more slowly than expected), so you can save yourself that pain. Matt and Eric claimed during the USRP development that it wasn't possible to build a USB-powered board that didn't (1) draw too much power, and (2) couple too much noise into the sensitive analog circuitry. Of course, their board has four hungry chips on it; yours will have only two. You might try building your first prototype boards with jumpers or solder bridges that will let you test with USB power and with wallwart power -- and see if the radio performs differently. In the USRP I had proposed that the clocks to the ADC's be programmable, so the whole processing chain could run more slowly than the maximum rate. Matt was unable to find clock generator parts that meet his jitter specs (which are critical for oversampling). That's why the USRP runs the ADC at top speed and downconverts using math in the FPGA. If your Blackfin can't accept data at top speed, you'll have to improve on the USRP's clocking. You prefer USB2 over firewire or gigabit Ethernet? It would be nice to have a radio spectrum interface that didn't have USB2's bandwidth as its bottleneck. Gig E is always full duplex (no collisions between transmit and receive), and offers higher bandwidth. GigE switches are now in the $100 range and dropping fast (or you can plug the board directly into a computer's GigE port, if it isn't on the Internet at the same time, e.g. for mobile laptop use). John Gilmore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Broadcast flag: FCC and MPAA Response Briefs
The American Library Association, EFF, and others challenged the FCC's authority to regulate equipment beyond the receive tuner, in its broadcast flag ruling. (The flag order requires that the tuner not provide its signal to equipment that would let consumers simply record the signal.) The court issued a letter questioning ALA's and EFF's standing to challenge the order. Standing is a legal doctrine that controls who is permitted to file suits; you have to be affected and not just be a bystander. EFF and ALA submitted a brief and declarations that detail how we and our members are affected and have standing. FCC's and MPAA's responses just came in; here they are, courtesy of EFF attorney and DTV Liberation Front organizer Wendy Seltzer: http://wendy.seltzer.org/media/fcc-flag-supp.pdf http://wendy.seltzer.org/media/mpaa-flag-supp.pdf Some of the earlier documents are here: http://www.publicknowledge.org/issues/bfcase More background is here: http://www.eff.org/IP/Video/HDTV/ John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] wfm_rcv.py works, but with half-second delay in audio!
I finally got a SMA cable to hook the USRP to my old 4937 tuner. wfm_rcv.py worked like a charm on the first try, tuning a strong local FM radio station. I cabled the computer's audio output into my main amplifier, which also has a traditional FM tuner. When I switched between the tuner and the computer audio output, I noticed that the computer output was about half a second delayed from the FM radio signal available thru an ordinary tuner. Any explanations? John PS: I'm using the tarball release from the Debian packages, not the CVS. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NCSA GnuRadio Effort
The sensor + radio fusion stuff looks interesting. I see why the Navy's interested. In the future, you should be able to talk to both radio and i2c devices using the USRP. Your current tuner board could be converted to a USRP daughterboard with minimal trouble (or you could wait for Matt's similar board). You could make a custom daughterboard that has nothing but plugs for i2c (or maybe you could use the basic rx or tx board for that -- I don't know if the i2c pins come out to the rows of headers or not). The USRP software provides a way to read and write to i2c devices (and there are a few on the USRP, including the ID EEPROMs). John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] signals/atsc question
(and while I do have access to an mc4020 board, it is not in a location that can receive ATSC signals and I'm not about to run coax all over the place). I have to start by saying: either moving the mc4020 board to where the antenna is, or running coax all over the place, will be MUCH easier than to do what's needed to squirt this fat a signal over the USB bus. The mc4020 board runs fine in the current GNU Radio 2.x infrastructure. (Maybe Matt or Eric, or someone else on the list, has some better ideas than what I discuss below. I'm not a signal processing guru, and they are.) I am using a 4937 frontend, so that gets the USRP a signal from 2.75 to 8.75MHz. The only way that I've been able to capture the signal reliably is by doing a DDC by -5.75MHz with a decimation factor of 8. This puts the signal nicely between -3 and +3 MHz, at 8MS/s with complex samples. In order to convert this to 20MS/s real, I've tried two approaches: There are about 10.76 Msymbols/sec in an ATSC signal, so you are going to have Nyquist problems if you try to represent them in 8M complex samples/sec. You'll need at least 10.76 complex MS/s. (Indeed you may notice that we were skating inside the edge by using 20 non-complex MS/s on the old hardware.) If we had a faster USB bus, the USRP could sample at a nice high rate, like 32 Msamples/sec, then convert those complex samples directly into shorts that the old code will be happy with, without any further glop. Unfortunately that would take about 120 Mbytes/sec over the USB bus. If we can coax the USRP into providing shorts rather than complex, we can transfer twice as much data thru our bottleneck. I think it can, but I'm not sure how to ask it to do that -- and 60 Mbytes/sec still wouldn't suffice. I'm a little surprised that the code in the USRP's FPGA doesn't do arbitrary sample rate conversion, which would let us just say Whatever the hardware sample rate is, don't worry about it -- interpolate those samples to 20,000,000 samples per second and hand them to me over the USB. That would let us design the sample rate to match the bandwidth available. Instead, the current FPGA code will only decimate by fixed integer ratios, e.g. it'll throw away all but 1 out of N samples for you, without doing interpolation, giving you little control over sample rate and thus over USB bus data rate. But even at 20 Ms/s, with 14-bit samples passed in 2-byte shorts, we've exceeded the capacity of the USB bus. It would be pretty easy to build a sample-packer that would pass 16 samples in 14 bytes (rather than in 16 bytes), which would save us 1/8th of the bandwidth. That would get the data rate to 35 Mbytes/sec, right at the hairy edge of what USB2 can do. To get more headroom, we could round or truncate the samples from 14 to 12 bits, again with FPGA code. (Indeed, a nice sample rate converter should probably also offer sample size conversion, letting you grab 20ksamp/s of 7-bit samples, or 32.778403 Msamp/s of 8-bit samples, or 55.3 Msamp/s of 4-bit samples, or whatever else you want. It might even be able to give you 20 ksamp/s of 16-bit or 32-bit samples, I don't know the math involved.) (C++ code on the CPU side of the USB bus would unpack these 14- or 12-bit, or shorter, samples into shorts again.) So, if all this nonexistent VHDL code existed in the FPGA, then you could do the sampling with the USRP. This is why I recommend doing it with the mc4020 board. Now back to the old code that you're trying to validate before you port it. The argument parsing in the old code was kludged to only let you select particular rates like 20,000,000 samples/sec (-s 20). Sorry. The bulk of the code is parameterized with the variable input_rate, which is a double. I think the vast majority of the code would work if you set that variable to any value that doesn't mess up the Nyquist rules. You can fix the arg parsing so that input_rate = atod(optarg) * 1e6; and then feed it whatever -s value matches your sample rate. (As you later convert the old code to the new framework, you'll want to notice and fix any part that isn't sample-rate-independent anyway...) exception of the pilot which isn't very pronounced. (Note that it *seems* as if the pilot is stronger on the original than on the converted -- see http://web.mit.edu/imirkin/www/gnuradio) It took careful antenna aiming and agc gain twiddling to get those nice pictures. And even more care to get signals that the code liked. Both of these methods yield similar results -- the gnuradio-0.9 atsc_rx happily takes the input, and generates an output TS file, with an error rate of 1. However, I have plugged this very same antenna pointed in the same way into my pcHDTV 3000 card, and it has no problems with the signal (maybe an occasional glitch). The pcHDTV card uses a chip that's specialized and engineered to do this job very well in a variety of environments. By contrast, you are only about the
