A couple suggestions..

1) Put the tuner at the antenna feedpoint.. then you don't have to worry about "pruning" to exactly the right length, choosing another operating frequency, and not being properly resonant. Or the trees moving in the wind, etc.  There's a variety of tuners suitable for this, and if you do it, then all those comments about worrying about coax loss from mismatch just go away.

2) Get yourself a bunch of 31 Mix toroid cores or beads and use those as your RF choke at the feedpoint, rather than your coil o'coax. The air core coax is fairly narrow band, and it's unlikely that it provides a good choking impedance at all frequencies. A nice lossy core with high Z over a wide band really knocks back the current on the outside of the coax.

http://www.audiosystemsgroup.com/RFI-Ham.pdf by Jim K9YC is an excellent description of how to do all this


Ultimately, though, getting a horizontal or inverted V up a bit higher is probably the easiest bang for the buck.

IQ outputs with fairly wide bandwidth, perhaps as digital outputs, might become more common. It's a pretty useful transitional step from analog knob radio to full on SDR, and would be nice for "sound card modes" and such.

I wonder, though about IQ audio inputs to the Tx chain: it would be useful.. If they're wide band, then you have problems with the FCC (how do you prevent out of band emission or bad image cancellation).

I could see a hybrid being very practical.. Basically a conventional SSB transmitter (e.g. audio input with 6-10 kHz BW) combined with a receiver with a wide output.  You could still do a cool waterfall display and click to tune (sending the Tx freq command to the radio).

And probably more useful today than a First IF output feeding an analog pan display.
Sure you couldn't do some of the fancier transmit stuff (predistortion, polar amplifiers, etc.) but the vast majority of hams interested in SDR wouldn't care.

Pricey, but I think one would buy these to fool with the technology, not as competition for an FT-817 or IC-7000.  You'd definitely be an early adopter.

These do direct conversion with pair of fast 16 bit ADCs.  The writeup references a polar amplifier, which is an interesting approach rather than doing a vector mod to a linear amp scheme.

I couldn't find a block diagram, which would be interesting to see.

Skin depth in Silver at 30 MHz is about 11.6 microns (0.4 mil).  At 3 MHz, 3 times that (*sqrt(10)).
http://www.microwaves101.com/encyclopedia/calsdepth.cfm

So if the plating is 0.4 micron, as given by KA4POL, you might as well not plate, because that's not even 5% of the skin depth.  Most of the current is flowing in the copper.  And if you had a nickle plate on the copper before the silver, it's even worse. A nickel "flash" is often done to help the adhesion, if it's going to get at all hot.  (and if you're plating aluminum, for instance in waveguides or chassis, they almost always do a nickel flash, because the copper diffuses into the aluminum)


Start getting up into UHF and it might be more worthwhile.. 300 MHz has a skin depth of 3-4 micron, so a really heavy plating would help.  At microwave frequencies (say, 7 GHz and up), silver plating is definitely worthwhile (at 30GHz, 1mm wavelength, skin depth is 0.4 micron)

The real advantage of silver (or gold) plating is that it is easier to solder to, because either it doesn't corrode/oxidise as much and if it does, the flux cleans it up much easier than copper oxide, sulfide or carbonate, all of which are very tough.

you might also look at:
http://www.w0qe.com/Technical_Topics/inductor_Q_tests.html

Silver does look pretty though..

The other problem is that the FAA doesn't allow such use of UAVs, except for experimental/research purposes, sales demos, and training.  There's a whole raft of rules around it:
1) hobby R/C is one thing, but doing for a business or to support a government agency requires much paperwork. (In 2007, the FAA clarified that AC 91-57 only applies to modelers, and specifically excludes individuals or companies flying model aircraft for business purpose.)
2) You need a "special experimental certificate of airworthiness" if you're not a government agency or doing work for one. Lots o'hoops to jump through.
3) A government agency needs a Certificate of Authorization.

You'll need to have 2 or 3 operators on the ground: one who flies the plane; one who is the 100% of the time visual observer, without aid of binoculars, TV, etc. 

Not particularly green, at least in the long run.  He's running a CRT monitor, most likely, and a pretty inefficient power supply/mobo in a "computations per joule" standpoint.

Saved money, it's true, assuming his time is free. Or if you're using it to heat your garage as well as do computation.  Or, just for the thrill of resurrecting a computer boat anchor.

But what about something like a Raspberry Pi (w/o ethernet), an old LCD TV and a keyboard.  I don't know if the rPi has a suitable audio interface.  You're still in the <$50 range, and you've got something that consumes orders of magnitude less power.

and a separate radio (since the Nexus 1 doesn't have a UHF radio).  The phone is used for its sensors and as a flight computer, not for it's radio.  PhoneSat 2 still uses an external radio (S-band).

S9= -73dBm so 40 over is -33dBm.. Against -142 dBm this is about 110dB of instantaneous dynamic range, or about 18-19 bits in the ADC.  So it's impressive that they held that level of performance through the analog processing chain, but not exactly world beater in a DSP radio (it would be very challenging using LC or crystal filters).
  There are a lot of other aspects of performance that will be important.

I'd be more interested in seeing what their output spectrum looks like.  How well do they suppress the DDS and the image? Over frequency, time, and temperature.  How well can they keep that adjacent channel performance over time, frequency, temp, etc. How often do you need to recalibrate to hold that performance.   Stuff like that.

You bet..
Flex started as a sort of hacker platform. Gerald provided the basic VB core to get it working.  Later, they picked up dttsp (in C) as the engine and VC# for the UI stuff.  The idea was that dttsp would be a nice reliable open source signal processing core, and that the bazaar would provide enhancements both for the dsp and UI. 
It worked fine for what it was.   But the user base grew (very quickly) and those users were not SDR hackers looking to scratch an itch.  They were hams wanting an inexpensive high performance radio to compete with the multikilobuck radios. I suppose you could say it was the transition from a prototype (the hacker platform) to a product (orders of magnitude more users than coders).

That said, Windows (while a pain in some ways) didn't make it horribly harder. Had they run under Linux from day 1, they wouldn't have had the transition: it would still be a hacker platform.  More importantly, Gerald would never have built the first one, because he worked in VB, and that's a Windows only product. I think it was a great thing he did.  He didn't get wrapped around the axle about needing a special DSP processor, or trying to link to some fancy DSP library, or even fooling with gnuradio.  To say nothing of the absolute PAIN it was trying to get audio devices to work under Linux was back in 2003.   He figured, hey, my PC is fast enough to do simple DSP in VB, why not build a radio. And he did.

ANd that motivated a horde of folks to get with the program and make serious efforts in PC based SDRs.  Phil Covington had an idea to build a SDR, and got convinced that it would be productive to build high performance audio interfaces to improve the performance of the SDR1k, and that got a lot of people involved in other SDRs.  There were a lot of bumps in the road there, too.  The SDR1K existing, or more properly, the existence of PowerSDR which was flexible enough to support other hardware prompted the development of the SoftRock, a very cheap SDR using a crystal instead of the DDS. 

Such things have been around for a while, and never got traction.  DSP-10 for instance.  The problem, fundamentally, is that there are relatively few people actually interested and skilled enough to fool with the DSP side of an SDR. So the sales volume of your radio will be small, unless there is "off the shelf" software that makes it work. Today, YOU could go out and build yourself an SDR with your processor of choice (use an eval board, like Bob Larkin did for the DSP-10).  But then you're constrained to work with THAT processor, and whatever you choose, it won't be as common as an x86 based PC. Pretty soon, that processor will be obsolete, you'll be running the dev tools in emulation, etc.   

For a more modern, and fairly well supported, device, take a look at Matt Ettus's USRP (also available from National Instruments). It's a nice hacker platform, has an FPGA, hooks up to gnu-radio.  Hundreds of them have been used by undergrads and grad students for senior projects, thesis projects, and PhD dissertations.  They're also used a lot in industry, and as "cell site emulators" for a variety of purposes, some good, some evil. 
Yes.. the USRP is what you want.  The F6.xK or the F5K or the F3, etc. are what the average ham SDR buyer wants: a turnkey box with easily installed software upgrades provided "by others".  I'm sure others will spring up in that market.  There are SUBSTANTIAL challenges: software development costs are but one (since "open source" did not provide a free (as in beer) option); there's also a host of regulatory issues.  It's one thing to sell a box o'parts to a hacker in small quantities; the FCC is going to let you do whatever you do, just like if you cobbled together a rig using that surplus PTO and those 6146 tubes you got from an estate sale, with some sockets you made by drilling holes in some beer coasters.

However, start selling a "box" with a "user manual" and such, and they're going to ask questions like "how do you block reception of cellular frequencies?" and "how do you prevent out of band emissions?" and "could you demonstrate that your spurious signals meet good engineering practice"

That's the "prototype to product" transition you mentioned, in real life..

No verilog or vhdl in a Flex. It's all C running on the PC.

The problem with low bands on Flex comes from the basic architecture.  It uses a form of vector modulator on a DDS produced carrier.  The I/Q signal is setup as a few kHz offset from zero (to get around problems with DC response of sound cards in the first flex).  If the I/Q balance isn't perfect, you get an image below the carrier, as well as some carrier feedthrough.

The way the (analog) modulator works uses a I/Q version of the carrier generated by a DDS that puts out quadrature outputs, but there are discrete component 7th order filters on the output of the DDS. They match pretty well, but not perfectly.  Ditto with the audio band I/Q from the sound card.

All potentially calibrate-out-able, but the calibration changes with temperature, carrier frequency, and isn't constant across the I/Q passband.   It's easy to get 20-30 dB carrier and image suppression with a single point cal (ignoring the above), and that works for typical HF usage, where the person receiving is seeing the signal at 20 dB above the noise floor (they don't see the low level carrier and image). When folks doing top band CW started running high power amps, all of a sudden, that 30dB image is pretty noticeable.

The original SDR-1K with the original sound card interface is doomed in this situation, because it has no DC response to take out the offset term in the I/Q.  I think the F5K has DC coupled DACs to the modulator, but I haven't seen a schematic, so I don't know for sure.

There were several schemes for a loopback "self cal" in the F5k design, but I'm not sure they ever worked well, or were really thought through fully. Essentially, you need to have a good receiver with good instantaneous dynamic range and good image control with which you can look at the transmitter output and adjust the image and carrier down to zero. You can theoretically do this with the receiver that's already in the radio, but then you have to calibrate the receiver first.  And you really need to be able to set the center frequency of the receiver to something different than the center frequency of the transmitter (so you can use the unmodulated Tx as a tone source to calibrate the receiver).  The SDR1K can't do this (it's a half duplex radio).  The published F5K block diagram is unclear whether a single receiver F5K can have different frequencies for Tx and Rx chains (the dual receiver certainly can), and I'm not motivated enough to go look at the controller source code to see if it can.

Cal Tech (W6UE) has a shack in Winnett Center on campus.  UCLA (W6YRA) has a shack on the roof of Boelter Hall.  There are a number of clubs being set up (or resurrected)  at Universities to operate cubesats.  Reading over websites and talking with folks, there's typically one or more faculty members who are the driving force behind the club staying in existence.  For most universities, there's some sort of process for resource allocation among clubs in terms of facilities.  As long as you're not consuming too much floor space, once you've got something, they're unlikely to throw you out (and in the case of UCLA's shack on the roof, it's unlikely anyone else wants the space, for instance).  Radio clubs tend to be fairly inexpensive to operate compared to a lot of other activities (e.g. occasional capital expenditures, but not much in the way of supplies).

At JPL, we have had a series of facilities for the club over the years, as have some of the other NASA centers. 

However, the OP was looking at clubs where there was a facility that served as a social gathering place, as opposed to an "operating location" or "shared shack".  For the universities and NASA or "shack at work" type places, I think that other things perform the "gathering place" function. 

It's also true that participation in "work sponsored" clubs and athletic leagues (bowling teams, softball, etc.)  has greatly declined over the last few decades (at least here in Southern California).  It might be that businesses aren't interested in sponsoring them, although I think it's more of a benign neglect, than any sort of "we are paying too much for it".  The change in workplaces and schedules is probably a bigger factor. Flexible working hours are great in general, but it also means that you don't have a "everyone gets off at 430PM and can go to an activity at 5PM" thing.  Some of it could also be that people commute longer distances to work.  There's also other time pressures: gotta pick the kids up from school/day care; cook dinner, do homework, etc.   In white collar type environments, effective working hours have gotten longer; both seat time in your cubicle, and with more "remote tethering" via the omnipresent mobile devices.   Increased telework also means that fewer employees are actually at the work facility.  There's also a trend towards companies not owning their permanent facilities. A significant number of jobs today are in knowledge work and don't require manufacturing equipment or anything else.  Where-ever you can put in network drops, you can do business.

This is fairly normal and not particularly unusual in the regulatory world. Any time there's a special case (e.g. an exemption for hams) one would ask whether you can do away with the special case (regulatory simplification and all).

Doing a decent RF safety evaluation isn't all that hard (it's a lot easier than learning CW). There's plenty of simple analysis that a ham can do that would assess the exposure, so the need for a "no analysis safe harbor" is sort of small.

There's also the "multiple transmitter" problem. The regulations require that if there is more than one transmitter, you need to do the analysis, not take the exemption.  And that's not just ham transmitters, the cell phone and the WiFi and the BT and everything else count too.  There's a "less than 5 percent" exception, but I would venture that the fields from the cellphone are comparable to, if not greater than, the typical fields from a HF or VHF antenna.

There's also this problem:"exempt transmitting antennas that are unusually close to people could potentially lead to non-compliant exposure levels"  

Pictures in QST of people running mobile VHF rigs or HF compact loops on picnic tables running 100W don't help things.

check your longitude and make sure it's the right sign or that you didn't drop a zero somewhere.

An interesting question.
There's not a lot of good books on DSP/etc tailored to SDRs in a general sense. There are textbooks like those by Proakis or Oppenheim & Schaefer (and used versions should be available less expensively than new), but they tend not to talk as much about non-ideal behavior (e.g. what does it look like when you clip into the ADC).  Partly this is because classical signal processing makes the assumption of linear behavior (or, at least, idealized non-linear: multipliers are perfect). 

When it gets to non-ideal behavior, you're getting into specific implementations.  Journal articles on various aspects of this are where the information is: for instance, spurs in DDS output is the subject of a variety of articles, and even a couple specialized books. 

I don't know that there's a SDR equivalent of, say, Rhode's "Communications Receivers" which is a great overall review of analog receiver design. (with some DSP, too).  There are a fair number of newer books out on SDR, but they tend to focus on data radios, given the fact that commercial radios are virtually all carrying data, not analog signals, and so the analysis tends to be in terms of things like effect on bit error rate (BER), or perhaps on error vector magnitude(EVM).

There are also an enormous number of useful applications notes out there from TI and Analog Devices on various pieces of the signal processing chain: ADCs and DACs are where the rubber hits the road in terms of performance, and there's lots of ap notes on them and their various non-idealness.

But.. if you're looking for a discussion of "typical spurious signals" you might find it a bit hard to find.  ARRL handbook has some.   In general, you're going to see the following kinds of spurious sources (over and above the usual ones from the analog circuitry):

1) clock leakage - intermods and sampling artifacts with the clock frequency and multiples thereof.  I have a receiver which shows an interesting spur that turns out to result from the 66 MHz CPU processor clock leaking into the 49 MHz sampling clock (or the power supply), so I see intermod products at combinations of 66 and 49 and multiples thereof, some of which appear in band.
2) aliases - there's no such thing as an ideal anti-aliasing filter, so you wind up with what would normally be out of band spurs showing up at in band frequencies as the result of aliasing.
3) DDS spurs  from phase truncation or from finite DAC resolution - there's a whole literature on this.
4) Spurs from overloading the ADC.  This can result in what are essentially intermods with the sample clock rate or multiples, that alias back into the sample bandwidth.
5) I/Q modulator leakage. Either the carrier getting through, or the image showing up.  40 dB is doing quite well for I/Q modulators, but 40dB down can be pretty big, if the desired signal is large, and it's often in an unexpected place, compared to what people expect from conventional radios.

Midi messages

That's not how it generates CW (nor how any SDR would generate it): you're thinking in terms of traditional analog radios where you do something like turn the final amplifier on and off (or perhaps one of the stages, and then feed it to a linear amp).

In an SDR, you just generate the sine wave (envelope shaped to reduce key clicks) that you want transmitted.  Think in terms of something like hooking the output of a code practice oscillator to the input of a SSB rig.

The challenge with the PowerSDR software architecture is that the latency through the chain can vary somewhat.  The transmitted signal is ok, but has a variable delay from the input to the chain, so if you listen to your own transmitted signal, you'll be confused.  The recipient on the other end of the path doesn't care.. he or she hears normal CW.  Another term for this is "pipeline delay" and such a delay exists in ALL radios (even analog ones).  The delay through a filter with a given bandwidth is roughly 1/Bandwidth * number of sections. So if you have a 50 Hz wide filter, you're going to have a 20 ms delay (at least).  In the Power SDR, the delay is more about the block size in the DSP. SHort blocks mean shorter absolute delay, but the filter performance isn't as good.  You want a 1 Hz transition in a brick wall filter? that's a 1 second delay.

The other challenge faced by the PowerSDR architecture is T/R switching.  In the early versions (fixed at least 4-5 years ago, I think), you had to wait for the audio buffer to finish before it could be "turned around" to the other direction. That's probably the "missing dit" thing.  When they fixed the buffering so that it ran full duplex (at a cost of doubling the CPU burden), that particular problem went away..

The other tricky aspect to the PowerSDR architecture is that it potentially has multiple blocks of data stacked up through the chain in both directions.  You really, really don't want to have the Transmit DACs "run dry" (because you'll be emitting a big CW carrier at the DDS center frequency with fixed values of I and Q until the next set of samples arrives), so you want to have a few blocks queued up, in case the PC decides to go do something else for a short time.  If you're watching a DVD and you hesitate a frame or two, you might not notice.  But if the last set of samples happened to be full scale I & Q on a Flex, then you're transmitting full power carrier until the next samples arrive.  A good design (which they may have done in the firmware between 1394/Firewire and DACs) would have some default "zero" value (chosen to minimize feedthrough of the DDS) to clock out if samples don't arrive over the firewire in time. 

In any case, the need to have extra blocks in the pipeline so the FIFO doesn't run dry also leads to longer delays.