The D-STAR issue is not really ICOM's fault. JARL designed D-STAR (not ICOM) and put the AMBE codec in it because nobody believed that you could have a good open codec at the time. We now have Codec2 (a project I evangelized and recruited the developer) which is fully open. And we do have a software AMBE decoder in Open Source, although the patents won't let us use it. That is why I am working on the patent issue (as noted in the last slide of the presentation).

I know about the counterfeit FTDI chips, and Matt Ettus told me what has happened with the Chinese clone of USRP. We know what to do.

And it's because of No-Code. We looked at the licensing statistics and thought we'd preside over the end of Amateur Radio in our own lifetimes. That's the main reason I worked on no-code. There was really strong opposition among the old contingent, and ARRL fought to preserve the code for as long as they could. Someone even asked me to let Amateur Radio die with dignity rather than sully it with no-code hams. Gee, I am glad that fight is over.

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.

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.

If you work for a government and pay me, I'll be happy to answer that question. :-)