No...you may have inferred that, but that's not what I was implying. What I was implying was that, since the app is designed to help people help the EFF achieve some of its goals, if the app were in the app store of one of the most breakout popular devices in the history of the entire world, it would thus make it possible for a significant number of additional people to help the EFF achieve the goals aimed at with this particular app.

But because they have decided that some of the principles behind what they want to achieve are utterly inviolable, and the Apple dev agreement conflicts with some of those inviolable principles, they clearly feel that they are therefore obligated to prevent anyone who owns an Apple device from using their app.

This is the kind of cut-off-your-nose-to-spite-your-face behaviour that really hamstrings a lot of efforts to improve the world. I'm not saying the ends justify the means—far from it. Just that when you're living in a badly imperfect world, insisting that you, yourself be perfect at all times while trying to make the rest of the world better is very, very often going to prevent you from doing more good than it actually does in itself.

Dan Aris

Well, I'm sorry for the EFF, then, but everyone knows what the terms are to get an app in the iOS App Store.

This sounds, to me, like the EFF allowing slavish adherence to their principles to prevent them from doing something that might actually help real people in the real world advance those principles in meaningful ways.

Either that, or they just realized they could use it as a publicity stunt.

Dan Aris

There's a partial list of fabs at Wikipedia. There are more than just those three.

Sure, process optimization per fab is an issue. We would probably need to start on the very conservative side.

A lot of the time, building a custom ASIC rather than using an FPGA just isn't an option. Most of the products I'm concerned with need to be programmable.

David Rowe makes a point about echo cancellers and voice codecs, which he's written in Open Source, working alone. They were supposed to be magic. They were supposed to take big expensive research labs to make. When he actually got down to the work, he found there wasn't really magic there. Codec2 can get clear speech into 1200 Baud, and OSLEC (the echo canceler) is part of every Asterisk system and other digital telephony platforms.

Steve Jobs also told me this when I was leaving Pixar. He didn't believe that the Linux guys could make a decent window system, because it had taken a Billion dollar research lab at Apple. Two years later he unveiled Safari, which was derivative of KDE.

There is no question that we can make a good gate array. The technology is very well known. Can we make one that is on the absolute leading edge of the technology? We don't really have to. Making a good one that was open would be enough. But maybe we can make a great one. That depends upon what makes it great. We have a collaborative advantage as far as the software tools are concerned, the same as with compilers. Can we design a really good logic element and fabric? Probably. Can we prototype a gate-array in a gate-array? Sure! Can we use the various devices that OpenCores has developed? I don't think there would be a problem. So we could have on-chip peripherals, CPUs, etc. Once we're sure of it, can it be well-tuned to a fab? Probably, but even if we are conservative about using the fab's capabilities it would work.

Yes. And looking at the way things have gone previously in JEDEC, we would have to be very aware of manufacturers desire to embed their patents in standards.

An Open gate-array is one of those "if you build it, they will come" sort of things. Chinese fabs would compete with each other to drive the price down. It would become the standard low-end part and gate-array manufacturers would have to compete on high-end only.

So I am really interested in doing it, and so is Chris. We just can't ignore our current business in order to do it.

Yes, we feel your pain. Indeed, it's our pain. Proprietary tools, and you get told how to load the bitstream but it's an opaque blob. We would like to work on this problem next. How far off that is I can't say, if we can establish a profitable land-mobile radio business (we don't expect to make much off of hams alone) it would help to fund such an effort.

Chris and I would like to do an Open gate array as our next project. Sufficient patents have expired, etc.

If you ever write a means of describing digital logic designs in Lua we can compare it. Just describing data structures is not sufficient, you need to describe parallel boolean algebraic operations and macrocells such as multiply. At the moment no such thing exists and it would take a long time to duplicate the work of the MyHDL project.

Not sure you understand. The OO model is useful for representing a 4-input device with a logical output determined by a look-up table, which is the fundamental logical element. At least it's useful to do it elegantly. Lua is a small embedded language, but the purpose of MyHDL in this case is not to execute Python at runtime but to generate VHDL or Verilog describing an inherently parallel implementation of an algorithm.

Chris can explain this much better than I, but we are definitely conscious of the gate-array resource use. Currently we are running within the space of the least expensive SmartFusion II chip, which I think you can get for $18 in quantity. Smartfusion 1 was more of a problem as it didn't have any multiplier macrocells and we had to make those out of gates. SmartFusion II provides 11 multipliers in the lowest end chip, and thus the fixed-point multiply performance of a modern desktop chip for a lot less power.

We are also aware of algorithmic costs. For example we were using Weaver's third method and will probably go to something else, maybe a version of Hartley.

HackRF is designed to be test equipment rather than a legal radio transceiver. It doesn't meet the FCC specifications for spectral purity, especially when amplified. You could probably make filters to help it produce a legal output.

Whitebox is meant to meet FCC specifications for spurious signals that are required when amplification of 25 watts or higher is used. Amplifiers also contribute spurious signals and will usually incorporate their own filters.

HackRF is something that sticks on your laptop via USB. Whitebox is meant to be a stand-alone system or one that is controlled from your Smartphone via a WiFi or Bluetooth link.

Whitebox is optimized for battery power. Using a FLASH-based gate-array rather than the conventional SRAM one makes a big difference.

Unfortunately, in order to get a deal that is even within 2 orders of magnitude of that, you can't live in the US. Anywhere.

Dan Aris

HackRF is designed to be test equipment rather than a legal radio transceiver. It doesn't meet the FCC specifications for spectral purity, especially when amplified. You could probably make filters to help it produce a legal output.

Whitebox is meant to meet FCC specifications for spurious signals that are required when amplification of 25 watts or higher is used. Amplifiers also contribute spurious signals and will usually incorporate their own filters.

HackRF is something that sticks on your laptop via USB. Whitebox is meant to be a stand-alone system or one that is controlled from your Smartphone via a WiFi or Bluetooth link.

Whitebox is optimized for battery power. Using a FLASH-based gate-array rather than the conventional SRAM one makes a big difference.