I feel the same way about some very prominent members of the US science and technology committees.

Though a nice compromise might be to allow such things in certain bands only.

That is why there are different radio services. Hams really only have a few corners here and there of the radio spectrum. There really is a service for everyone, although you should be aware that the entire HF spectrum would fit in a few WiFi channels, and all of the Amateur HF spectrum would fit in one. So, we don't really have the bandwidth at all. And people who want the bandwidth on UHF already have WiFi and the various sorts of RF links, etc.

The internet really sucks and we don't want another one on ham radio. Nor could we possibly have the bandwidth to support one. The entire HF spectrum fits in just a few WiFi channels.

To satisfy the demands of the "it should be anything goes" crowd, we have CB radio. And there are all of the common carriers, etc.

So, I can't sympathize, and even if I did, there are not the technical resources there.

Sorry.

I am afraid that's not the way it works. Public-key encryption doesn't really give you the capability to decode the communication of two other parties unless you get the secret (rather than public) key, which they have no reason to give you. There is also a session key that is randomly generated and lives only for the duration of the connection, and there is the potential for VPNs or tunneling that further obscure the actual communication. It's actually very difficult for a monitoring station to even get 100% of the packets reliably, although the two stations in the communication do get them. So you may not be able to reconstruct all of the bits in the stream, and this will break decryption too.

All of this adds up to so many technical hurdles that in practice you have to be NSA to decode the communication, hams who are attempting to self-regulate will not have the appropriate resources.

Except that a lot of people really like the flat look. That's why Google, Apple, and Microsoft have all adopted it. They're not ignoring customer feedback, they're chasing after it.

Don't assume that just because you think something is ugly, everyone else agrees.

I just want to interject an opposing point of view here. It's very easy to think that icons don't matter, and that the only thing that matters is some kind of 'objective functionality'. Like, "Windows boots up, it runs the things I want, it has the features I want, therefore icons are irrelevant." I can think of few reasons, off the top of my head, why we shouldn't be so dismissive of design.

First, design matters for the sake of clarity. In the example of icons, you want to make sure that it's clear which image is an icon, and which is some other design element. Which images are clickable? What does that image represent? Those questions are important for UI design. Further, it's important that icons are distinguishable from each other.

As much as possible, you want icons to provide a cue to the user as to what will happen when you click on that icon. If you're going to have one icon for a folder that contains music, and another for a folder that contains images, you don't want them to look close enough that they can be confused. Going further down the line of thinking, if you're going to use the "folder" metaphor, then you probably want to make all 'folders' have folder icons, and have no applications have icons that look like folders. Consistency is also very important in making a UI intuitive and usable.

But all of that is still a bit in the realm of 'practical' and 'functional', and I'd want to make an additional argument that it matters whether a UI is 'pretty'. In short, you have people sitting in a chair looking at these images for 8-12 hours per day, and design aspects of the interface have to have a psychological impact on a person. It would be subtle, in that I would bet small changes have essentially no effect, but still important, in that I would bet that a drastic change in UI 'prettiness' could have a major impact on a person's mood and even productivity over time.

TDMA is time-division multiple access. It just means dividing the channel into time-slots, where each is some number of milliseconds. So, say we had two slots, each 20 ms long. We could receive for 20 ms, and then re-transmit what we received in the next 20 ms. No duplexers, no front-end overload, just one frequency. Works really well with digital modems and voice codecs.

Actually the nature of the content does have relevance. It absolutely must not be commercial. Now, give me a way to regulate that when I can't break the encryption.

And if you are about to tell me that you should be allowed to do commercial stuff on Amateur Radio, you won't gain any sympathy. That's what your cell phone and a dozen other radio services are for. This was never meant for you to check your gmail, etc.

I think you should assume that your desires were simply incompatible with the service, and that both you and the hams are better off that you're not participating.

If we put in every feature, we'd never get done. Maybe we'll have a 0-to-SHF radio eventually.

I think Javier Serrano at CERN wants to fund improvements in Kicad and gEDA. I don't know enough about them myself. Chris has his favorite PCB program and I didn't force him to use something else.

But you think that's bad? The gate-array has a proprietary bitstream. You need a zero-cost but proprietary program to make it. That's the one that really irks me. We hope to work on that issue eventually.

Actually it makes a good TDMA repeater. That means that it can receive and transmit on the same frequency, in different time slots. And it can carry full-duplex that way too.

It won't cross-band on its own. The I/Q transceiver chip won't transmit and receive simultaneously, and there's only one VFO.

If everything goes right, we will crowdfund an assembly run in a few months. But it's got to be working completely first and through a short manufacturing run. We won't crowdfund and then make you wait while we design and debug it, as some other projects have.

Very nice project.

There are healthy projects like OpenHPSDR that incorporate all of those things you don't like. Our radio does for VHF/UHF what OpenHPSDR does for HF.

We're trying to create the platform that can host a decade of software innovation. Thus, we do pay the cost of being on the leading edge. There will definitely be cheaper radios.

We're not selling kits. Either working PCBs, or complete radios. The hardware isn't under an Open Hardware license, although it's close.

The filter board slots are in the slides. Only one of the filter boards is shown. That one is meant to get spurious 60 dB down, but we've not tested it yet.

We have all of the right test equipment. Our main spectrum analyzers are Rohde and Schwarz FSIQ's, we have a high-end Agilent frequency generator, an HP Vector Network Analyzer with S-parameter test set, a GPS disciplined oscillator for the house frequency standard, a Faraday cage and an RF anechoic chamber, a lot of surface-mount assembly equipment, etc. I bought it all for cents on the dollar from companies like Nokia and Motorola that were shutting down R&D, the U.S. Government, etc.

By using gate-arrays, we get around some of the problems of unobtainable chips. We can move our design into different chips.

This particular design has an I/Q transceiver chip, and that's the only non-general-purpose chip. There are other IQ transceiver chips to which we could port our design.

Is there some standard way to manage timing? Does the weekend hacker need to deal with signal/buffer latency from the DAC/ADC or somehow manage timecode synchronization?

The DAC and ADC are clocked by the master 10 MHz oscillator, and there's a gate-array that you can program all sorts of hardware timing into. But if you are actually dealing with radar I would expect that you've already joined this mailing list.