Slashdot Mirror

Also, dsto and another unit

jm

That's one way, but I think that instead of blocking the signal, you should ensure that it always has a strong signal.

It's also illegal to sell or manufacture a device capable of intercepting cell phone conversations.

Man, I wish the Gnu folks would build their own hardware card rather than the card they are currently using - it's quite expensive.

I'd love to see them put a decent FPGA, an Intersil 50216 4 channel digital downconverter, and a nice 60 Msample/sec 12 bit flash A/D converter on the card - they could do that for a bill of materials of about US$200, and have enough power to do the capture properly.

Before you say "Fine - why don't YOU design it?": I'd love to get more involved in GnuRadio, but I'm afraid of potential conflicts of interest both ways - contaminating GnuRadio with my professional work and possibly exposing my employer to problems with GPL infringment.

Also, is anybody big in the Gnu Radio project going to be at IWCE (International Wireless Convenention and Exposition) March 10 - 14? If so, where? I'm getting in on an exhibitor's badge - maybe I could get pictures?

How close are you to getting your degree? Depending upon the kind of work you do, you might want to throw a resumee our way.

DSP, RF, networking, Linux. Fun stuff.

I love the fact that a good, Free Software voice codec is out there, and here are my reasons:

1) Ham Radio. The Tucson Amateur Packet Radio organization is working on experimental digitized voice over amateur radio applications, and a couple of venders (mostly Kenwood) are offering radios that have this ability. Right now, TAPR are looking at using DVSI's IMBE vocoder, which is QUITE expensive and VERY not-Free. The availability of a Free codec would greatly improve the availabilty of this protocol.
2) Currently, The Association of Public-Safety Officials (APCO) (the folks who define the specs for the radios used by police, fire, and government) have defined the current digital trunked radio standard, APCO Project 25 as using DVSI's IMBE vocoder. While this is licensed under a Reasonable And Non-Discrimitory license, if you want to license the IMBE vocoder for a P-25 project, you will cough up US$100,000.00 for the privilege (I know firsthand, as the company I work for has done this). Uniden, Radio Shack, and other scanner companies are looking into putting this into their scanners, so they have had to cough it up as well. A Free vocoder would allow anybody to build a product with this capability in it - you could even use a scanner and your sound card to decode the Phase 1 C4FM format signals.

Like so many other things, a Free Software tool to do these things would greatly accelerate the industry. I hope Xiph does well.

I'm sure you were just being funny, but you wouldn't normally try to burn something like this onto an ASIC (application specific integrated circuit) - you'd compile the VHDL and load it into a big hoggin' FPGA (field programmable gate array).

An ASIC is a chip you have MADE in a foundary - once it's fabbed, it is no more reprogrammable than any other chip. An FPGA is a collection of omni-purpose gates that are controlled by SRAM or flash - you can reprogram it to do what you want just be hitting the reset line and loading a new image into it. At work, we (obdisclaimer - what I post on /. is my opinion, not my employers) use FPGAs to do a lot of signal processing.

The bad thing is that an FPGA big enough for a decent accelerator would be about a $700-$1500 part.

Now, what I can see it somebody doing enough devel on this to make a viable part, then getting it burned down to an ASIC and made avaible to the community. Yeah, that worked really well with IBM/Moto's CHIRP PowerPC boards.

But what could happen is this chip could find its way into the next generation TiVo, or some other set top box. In that market, a synthesizable core that was royalty-free would RULE.

I agree with some of the other posters, though - ditch the damn VGA compatibility layer, and just make a Linux (and *BSD) kernel console driver for it, an XFree driver, and a very basic BIOS driver for it. The BIOS driver can be stupid - just enough support to set modes, and print text. The kernel driver can take over once the system boots. Don't waste silicon making the framebuffer compatible with VGA (and thus EGA (and thus CGA)) - that design is a flat-out nightmare kludge. Go for a simple, clean, legacy-free design.

And while you are at it, make sure the DMA path is secure - make sure you can program the chip so that a vertex list entry cannot corrupt system memory. I lurk on the DRI mailing list, and the lengths to which they have to go to keep the graphics chip from being an exploit are ludicuous. It slows down the DRI drivers relative to other so-called operating systems that don't concern themselves with security.