Thanks for your post! I appreciate the info.

Sorry, this is incorrect, as far as I know. You might be thinking of various "automatic vehicle location systems" (AVLS), or perhaps there is a smartnet feature I'm not aware of. Our local police and fire use a disjoint AVLS solution from the smartnet. The police AVLS is in the clear, but requires pinging the car, causing a chime in the car. The fire AVLS is always transmitting. There is good reason not to encrypt the police AVLS -- it is only queried during emergencies and at those times it is critical that the request get through. The countermeasure for the lack of encryption is the in-car chime.

Savoring the "accuracy" now... Mmmmpf. Somewhat tasteless in that regard.

By "linux support," what I mean is either a working USB driver for it, or a data sheet if there's no USB driver. The bladeRF is open hardware, with even the schematic available and all chips having public data sheets. A device that does not support linux would be a device with no programming information and no driver. I imagine they exist, but maybe I am wrong and there is no such device in the existing market of devices made by hams.

You claimed this device wasn't as good as the devices which already exist. That is why my argument is not a "straw man" but a "prove that." I actually have an application for this device, but you claimed that the device was not as good as others already available but intended for the Ham market. As it turns out, the device is a better deal for my application than anything out there.

The only negativity I've read toward this project has uniformly been from Hams. From that group, there has been a generally dismissive tone of, "sniff, it doesn't go down to kilohertz..." As a group, you seem to be anti-anything that isn't for Ham applications.

The negative comment you posted is your fault. Yes, it was modded up by dummies, but you posted it. Why do people need to see your negative opinion as the first post? That was pretty lame, in my book. You're not just some guy on the Interwebz when you top-post a fund-raising article with a disparaging comment, you're a negative nancy with some say in the outcome.

BTW, of course "tap" for "trap" was a typo, as you can read in my post there are several other occurences of the word "trap" spelled correctly. Your suggestion that I might have been regurgitating your typo, as if I wouldn't know a "tap" from a "trap", is again an occassion where you are tripping over ego.

WUT? Have you considered, oh, I dunno, PCI Express x16? They do make extension cables for that, to get outside the chassis.

I can't help but notice that you weren't able to come up with an example of a better SDR for my application. "cuteSDR" doesn't seem relevant because I write all my own code to control the radio, demodulate (FSK/NFM) the signals, correct the parity-checked bits so the CRC matches, decode the content, etc. It's really irrelevant, because I asked you to name a piece of SDR receiver hardware which fits my bill and is cheaper than $400. I am all ears on that subject, but I don't need any pointers to software. I was asking you to substantiate your pooping on this project by providing an example of an SDR device that would be better for the fun I am having, not the fun you are having. You seemed to gloss over that for some reason.

Public agencies trunked radio, with whom I am cooperating on a proprietary application. Sorry I can't say more than that, but the signal of interest is Motorola SmartNet in my case. The application sprang from having fun monitoring it, and observing the potential for an improvement to their system.

No, none of the dongles have FM broadcast band traps, and the antennas are directly connected 800Mhz 1/4 wavelength dipoles. These are both purchased and home-built antennas, I have several of these dongles. I think you missed the part where I can easily pick up very weak and distant 120MHz signals (yes, using the 800Mhz antennas) which use the same front-end filter as broadcast FM, when we are talking about e4000-based dongles. The FM station nearby is so powerful that I owned several devices (telephones, computer speakers) which I've had to replace because the station was audible on their output. And yet, I can hear airplanes that are 50 miles out in the 120 MHz... I realize the 800MHz antenna is slightly antenuating the 95MHz FM signal, but it's also attenuating the 120MHz air band.

At this point, don't trip over your ego. I'm knowledgable enough to be sure there is no front-end filter of any sort reducing the FM broadcast stations. I understand there is a culture around talking up the trickiness of RF, but let's get past that for the sake of reality.

So, surely an expert amateur radio operator such as yourself will realize that 8 bits gives 50dB dynamic range? Which of course is awful. Yet this overload problem doesn't seem to be real.

Are you aware the e4000 data sheet is "out there" on the web? Between the antenna and the A/D, I've got: an ESD diode with 6pF capacitance, the e4000 front-end filter and LNA, the e4000 mixer, 5 more amp stages, decoupling caps, then the A/D, then, the single worst part, a "mystery" (undocumented without NDA) FIR with 20 taps. Why you would imagine that a $20 dongle could arrive with an FM broadcast tap is beyond me. The dongles aren't even shielded, and I can easily pick up the FM broadcast with a shielded 50-ohm resistor connected across the antenna input...

I'll give you that it is likely that the FM station is always contributing to my noise floor, but, realistically, the noise floor of the e4000-based devices is already horrible, with an 8-11dB noise figure, lots of birdies around the multiples of 28MHz and 5/3 of that. If any signal were going to swamp the dongles, I would expect that to be 480MHz USB emanations -- in particular because there is no way to attenuate them via adjusting the front-end LNA gain -- the signal appears to intrude after that stage. Yet I can receive at 450MHz just fine, and that is in the same front-end filter band as 480MHz.

It's true those are all present, but "interesting" is in the ear of the listener. None of those qualify as "interesting" in my book.

You mean like VOR? Those are up in the low 100MHz, of course...

Army ground is 40.5 MHz, again 40.5 > 30. Are there other military signals (we'll get to ELF in a minute)? What utility signals are below 30 MHz? I see them in the 400s around here.

Ok this is a little interesting, I'll give you this one.

Ummmmm. Those little buggers use radios?

These are on ELF, I'll give you that. But they are encrypted, of course, and they are also immune to traffic analysis. What is fun about monitoring them? Plesae don't tell me these are in the clear...

What is interesting or useful about this, especially given the GPS timebase being globally available?

One person's interesting is another person's ridiculous, I suppose.

You mean 27MHz R/C? The servo signal seems particularly boring, unless you are operating the R/C device, in which case you can look at it.

All of these are somewhat interesting, I'll give you that.

I'm having more fun at higher frequencies, I assure you. I think 1090 MHz is more interesting than anything you mentioned. 121.5 is worthy of note. The 450s and 850s (public safety and government) are pretty interesting to most people. Other people enjoy trying to figure out SCADA traffic in the 400's.

My complaint with your Score-5 first post is that you are pooping on a great project because your personal interests don't align. You're a ham. You think that is interesting. Good for you. As a ham, you also have a certain "authority" with some people. That authority is misused or misplaced when you dismiss a good project on the basis of having made an engineering decision that fits the interests of others, but not yours. I am very interested in getting access to the 2.4GHz wi-fi spectrum at the level of the signal. But my interests are more in software, software security, and things like that. So this particular SDR example from RFSPACE is of pretty much zero interest to me.

Ok, I am looking for an 858 MHz software defined receiver with at least 19 MHz spectrum bandwidth, and 8-bit samples work just fine for me at present. What's the most cost-effective solution for me at present? I only run Linux, so exclusively Windows support will be unacceptable.

I couldn't care less about Ham bands, but 450 MHz and 120 MHz would be "nice to have," as well as 1090 MHz. But I only need 850Mhz - 869MHz.

This bladeRF looks perfect for me.

By the way, I live a few blocks from a commercial FM station and use the RTL-based dongles at present. I don't have any problems with overload, even when tuning 120 MHz (same band in the e4000 LNA). I don't think the dongles really have the problems you stated. They do have a lot of problems (particularly birdies, and a high noise figure), but the concern about overload is urban legend.

So, I went to visit RFSPACE... With regard to the SDR-IQ:

LOL. What is the use of that for a non-Ham?

Your involvement with this might be the reason you didn't do enough research on whether bladeRF is HF-capable.

You mean "up-converter," but obviously you are correct that there is an easy way to bring signals up to this device, whereas there would be no easy way to bring 3.8GHz down to a lesser device, such as an RTL-based dongle.

Well that's a brilliant question. Let's suppose we obtained 10 Gsps. How would we send those samples to the computer? Two E-SATA cables, maybe? It just doesn't seem very doable.

I wanted to correct my own submission.

First, the bandwidth, or amount of spectrum that is instantaneously analyzed, is 28MHz, not 20 as I wrote.

Secondly, some troll^H^H^H^H^H nay-sayer posted that this device cannot be used for HF. In the first place, the device can receive and transmit 0-20MHz because the baseband signal pins of the ADC and DAC are available on a header. In the second place, up-converters easily solve this "problem," whereas hitting 3.8GHz is a great advantage to this device.

It covers 20x the bandwidth of an RTLSDR dongle, for 20x the price, and it also transmits and has an on-board FPGA and Arm9. So you are probably wrong.

Actually, the bladeRF has baseband input with 20MHz bandwidth, and same with output. The ADC and DAC pins are available at the baseband signal. So perhaps your nay-saying is motivated by ignorance or jealousy.

I wanted to correct my submission by adding: the actual bandwidth (amount of spectrum which can be processed at any one instant) is 28MHz, not 20.

The 40 M samples per second are quadrature samples, allowing 40 MHz bandwidth within the Nyquist limit, and there are internal low-pass filters limiting the bandwidth to 28MHz. Not pushing the sampling to the limit of Nyquist is a good thing -- the signals which are passed will be sufficiently sampled that none can slip by undetected.

With this large bandwidth, the bladeRF can effectively replace 20 of the RTL-based receivers, at a proportional cost, but the bladeRF also transmits and has on-board computation.