Direct Digital Sampled RF Transceiver

[Saber]

Anyone here ever tried something like this?

This is a project in the making, that has been going for a while now (mostly conceptual/planning/reality checks up till now).  This is possible with current technology, but bloody expensive to pull off.....that is if you are "allowed" to buy the components (ever tried to buy radiation hardened FPGAs before?).

My initial requirements were:
- HF right up to UHF (0 - 500MHz) - all HAM modulations (including squeezing Codec2 into there)
- No decimation/mixing in hardware at all
- DSP for everything between the ADC and DAC (16-bit)
- Initial implementation HF only, but solution had to be able to go to a 500MHz modulated signal.
- and lastly, a simple digital LCD screen/touch/knobs/speaker solution to fill in the rest of the radio (preferably classy - technology without aesthetics is just not on).

The whole idea behind this is to filter and amplify your RF signal, and then directly sample the RF signal via the ADC, and everything leaving the DSP would exit through a DAC. All further processing (IF mixing, filtering, modulation, demodulation) is done digitally. Although it might look like a pointless exercise, it can be done....and I think one reason might be to separate the RF standard(s) from the hardware. If anything changes, you just update your firmware. Another reason would be to start implementing the open source Codec2 into hardware (I'm a big fan)

Now......I know it can be done in ways that are a lot easier and cheaper....not the point.  I want to do it this way. My problem is running into FPGA/DSP limits for the required 10Gbps LVDS serial Iine I require for the sampled data. My initial though process went down the route of DSPs with high frequency ADC/DACs, but after eventually locating the DSPs that had the oomph to do what I needed it to do.....I discovered better ADC/DACs, and the DSPs cannot keep up anymore (the story of my life....starts to look like my 25 year old fiber home automation system - don't ask)....and the Freescale DSPs are friggin expensive.

I have now (sulking) scaled back the initial concept. I can use cheaper ADC/DACs, but I'll have to stagger them to stay within the performance limits, and I've decided that FPGA is a better route to go (the FPGA would also be better at regulating the staggered ADC/DAC clocks with minimal jitter). I am now also prepared to decimate in hardware to get the I/Q signals (sulk).

Have anyone here ever done something similar to this? Experimental/commercial/professional, I don't care. If you have any guidance, input, or ideas as far as is possible on component selection, possible architectures. I'll appreciate it.

This was hard work. Opening a can of Windhoek draught now........ (what?, no icon for beer? this is just not on in the engineering world) 

Regards

Johan
 

[PA0PBZ]

Did you ever google SDR?
The common way to do this is ADC and FPGA as a frontend, then send IQ to a PC and do baseband processing there.
Decimation in the FPGA, for most stuff you really don't need the full bandwidth.
As an example look at the block diagram of the QS1R.

[uncle_bob]

Hi

What you have described is essentially what is in a < $20 USB SDR dongle. They have simply smashed it down into ASIC's rather than stopping at the FPGA level.

That said, sure it work. Conceptually it is the way about 99% of all the receivers are done these days. (They make a *lot* of cell phones). You do it with different parts depending on your production volume.

Bob

[Saber]

The point is to do this as a standalone transceiver. Just like a normal HAM base station, just digital all the way. Most of us HAMs (and techies) like our switches, and buttons, and lights, and switches, and buttons, and lights......the more lights the better.

I do understand that functionally, everything I want to do exists, but there is still something to be said for sitting in front on a device with buttons on it........like a real scope, or speccie, or gennie (wondered why the USB scope never caught on). .....and whether we like it or not, the analogue HAM station is on it's way out.....we need a replacement.

Johan

[uncle_bob]

Hi

People do make radios like you describe. Regulatory limits restrict what they can do transmit range wise. Last time I looked, you could do pretty well on a full range of knobs / buttons / dials / lights and have digital inside for under $10K. For the "plugs into the computer and displays there" the price is quite a bit less.

The why on the price mostly relates to volume of manufacture and tooling. You don't see a lot of them because people don't thunk down that kind of money on a single toy very often.

Bob

[Saber]

Uncle_bob.....KACHING.....

If we wait for Yaesu, Icom, Kenwood, we are going to get overpriced radios (again), that is if they are prepared to continue manufacturing radios for HAMs in the future (small market).

$10k in ZA accounts for a few years of income for some people (and I'm not talking about squatters).

FFS.....we are all mostly engineers, aren't we? David Rowe (PhD in audio coding) created one of the most efficient, low bandwidth, real-time, codecs available today....open-source. Let's continue the trend and create hardware to match....

Johan

[Saber]

...btw...you cannot go for regulatory compliance until you actually have something....very important to consider, but not a problem on day one.

Johan

[uncle_bob]

Uncle_bob.....KACHING.....

If we wait for Yaesu, Icom, Kenwood, we are going to get overpriced radios (again), that is if they are prepared to continue manufacturing radios for HAMs in the future (small market).

$10k in ZA accounts for a few years of income for some people (and I'm not talking about squatters).

FFS.....we are all mostly engineers, aren't we? David Rowe (PhD in audio coding) created one of the most efficient, low bandwidth, real-time, codecs available today....open-source. Let's continue the trend and create hardware to match....

Johan

Hi

I've run electronics business over the years in addition to being an engineer. There is no way you are going to come up with a product to compete with the Japanese at a lower price. Your volumes will be lower and your tooling costs will eat you alive. For what they do, the Japanese radios are dirt cheap. In some cases the top of the line radio sells at a loss. It's just there for the prestige factor.

Bob

[Saber]

Not trying to compete with anyone, or start a business. Ever heard of the love of a hobby?

Anyway, if you have nothing to contribute (positive or negative - and you provided neither), I'd prefer to hear from the real engineers.

Johan

[donmr]

That is NOT a $20 SDR, those mix the signal down first then sample it.

Look at the HPSDR project, they did it for up to 60 MHz.

To get 500 MHz you will need 1GHz A/D(s), tha twill cost a lot.

[AF6LJ]

These folks have been doing what you are talking about however not to the extent of making it to 500MHZ that is going to be a bit much...
http://www.flexradio.com/

[uncle_bob]

Not trying to compete with anyone, or start a business. Ever heard of the love of a hobby?

Anyway, if you have nothing to contribute (positive or negative - and you provided neither), I'd prefer to hear from the real engineers.

Johan

Hi

Here's the problem with that. When you shut out anything you "don't like" it's not much of a conversation.

Indeed I have designed and built these sort of radios and do very similar stuff of a living. It that's not a qualification for being in the conversation ... it's a pretty exclusive club.

Bob

[ConKbot]

Selectivity is what makes good receivers good.  How would you handle a ham transmitting at few hundred watts on one band when you're trying to pull something in down in the dirt on another band? I.e. A random yaesu unit I looked at had a sensitivity of 0.2uV or -120dBm. If you dabble in a few bands, and have an antenna array, and your neighbour ham is putting -30 dBm into your antenna, you're eating up 90db of dynamic range before you even get to your signal.
You're looking at a 18+bit ADC to even consider that.  A few hundred dollars just into the ADC.
At least with the SDRs it's bandlimited to 60MHz or less (depending on model), so once you're into the shorter bands, there is some selectivity.

[uncle_bob]

Selectivity is what makes good receivers good.  How would you handle a ham transmitting at few hundred watts on one band when you're trying to pull something in down in the dirt on another band? I.e. A random yaesu unit I looked at had a sensitivity of 0.2uV or -120dBm. If you dabble in a few bands, and have an antenna array, and your neighbour ham is putting -30 dBm into your antenna, you're eating up 90db of dynamic range before you even get to your signal.
You're looking at a 18+bit ADC to even consider that.  A few hundred dollars just into the ADC.
At least with the SDRs it's bandlimited to 60MHz or less (depending on model), so once you're into the shorter bands, there is some selectivity.

Hi

Even more practically, you have the basic issue of keeping your transmit power all in one band. It may be a hobby, but there are rules

The same (likely band pass) filters that take care of the transmit can help you with the receive. You still have the problem with Bob next door running a KW 10 KHz up the band. That's a problem with any radio out there.  Some sort of filtering and sub-sampling might also keep you from needing to go shopping for 16 to 18 bit 1.25 GS/S ADC's with 120 db SFDR.  (500 MHz plus Nyquist filter gets you to above 1 GS/S otherwise). You do get *some* benefit from decimation so exactly how many bits .... TBD. Dropping the rate might also impact your FPGA cost quite a bit as well.

Bob

[AF6LJ]

This is an interesting discussion; I once heard a talk at a local hamfest by a gentleman who was well qualified to discuss the subject we are here. One of the biggest limiting factors of direct sampling, or for that matter just about all the current crop of SDR radios is receiver dynamic range. There is all kinds of software slight of hand that can be used to reduct the spurious emissions to an acceptable level but with even a 16 bit A/D converter dynamic range is limited to levels that are well below state of the art receivers and even many from years past.
http://www.sherweng.com/table.html

[cdev]

Are you sure?

Sometimes, the more direct perhaps the better, when the alternative is shift signals to some IF from every which where - at least in solid state equipment that seems like a process prone to creating spurs.

There is no comparison between a good SDR and most conventional radios..

8 bit SDRs though, I totally agree... With waterfall displays sometimes a screenshot will tell you more than an audio report about the ability to receive a wide dynamic range.  the cleanest screenshots I have gotten with a DVB-T dongle have been direct sampling.

But the gain is hard to get right. Its never quite right, you have to ride the gain a lot. Also, use attenuation, preselectors, etc.

[uncle_bob]

Hi

A 1970's vintage high performance radio will have filters in it with -135 db ultimate selectivity. The synthesis chain in that same radio will be spur free to a similar level. That level of performance simply got better as time went on. Commercial grade VHF radios in the 70's had similar specs (they stated them a bit differently).

An ADC (let alone a > 1 giga sample part) with a SFDR past 100 db is not a common item:

http://www.analog.com/en/products/analog-to-digital-converters/high-speed-ad-10msps/high-speed-ad-10msps.html

Sort by sample rate first and then look at SFDR. The first two parts are the only ones that give you a chance at 500 MHz. The faster one is 12 bits, the slower 14 bits. The 14 bit part has a 77 db SFDR. You can run through the whole > 10 MHz table and not spot anything with a listed SFDR past 100 db.

Decimation tricks and processing gain *will* help your noise issues. They will also add a bunch of bits. None of that takes care of SFDR. You can only fool mother nature just so far.

Now, how much range *do* you need? Sone designs seem to be ok at 60 db. If the objective is a super radio that beats anything on the planet, the spec's are a bit tougher. Out in nowhere on an empty band is not as much of a challenge as 10 guys in town all going power crazy.

Bob

[cdev]

Here we go..  more bits, less bucks.. Just get a better sound card.. You may already have one.

QSD is inherently also a good band pass filter!  This is what Flexradio and Softrock and a lot of other quite economical quite good SDRs use. It really works well. Its like a rotary switch, click click click click.

http://www.google.com/search?q=quadrature+sampling+detector

http://www.google.com/search?q=tayloe+mixer

So your sound card is your ADC. And thats around the cheapest high quality ADC you are going to find anywhere and it works in the low frequency domain so the QSD converts your signals to that.  I and Q.

Ideally, you then get a 24 bit sound card that can sample at 192 KHz..

 24 bit sampling is substantially better than 16 bit. the difference is really quite dramatic. Its much much better than a 55 or 60 db dynamic range in an RTLSDR, it seems to me. 

Absolutely no comparison. With an RTLSDR you almost never hear the weak stuff at all.

You want to maximize the voltage the sound card input can handle - so that it can handle the full voltage that the receiver can output without clipping. The floor is whatever the input noise reads when they are shorted.

Also, you should use offset tuning so you are never smack dab on the middle.

[uncle_bob]

Hi

If you have a sound card as the digital part, the best you are going to do for bandwidth is ~ 200 KHz. To do that without weird stuff happening, you need stuff like mixers (samplers) and a variable clock (synthesizer). You also will need something ahead of the sound card to take care of Mr Nyquist. (= selectivity)

The practical real world solution is to sacrifice SFDR for simplicity and lower cost. The radio isn't quite as good, but it is the best one you can build. It has other areas where it blows the old analog beast out of the arena. It is only when you say that you want the best of all things all at the same time (possibly at a real low price as well) that the process goes "tilt".

Bob

[cdev]

Hi

If you have a sound card as the digital part, the best you are going to do for bandwidth is ~ 200 KHz. To do that without weird stuff happening, you need stuff like mixers (samplers) and a variable clock (synthesizer). You also will need something ahead of the sound card to take care of Mr Nyquist. (= selectivity)

Yes, youre right.

Not even 192 KHz, with your 192 KHz sound card, you will get a solid maybe 180 KHz bandwidth with rolloff at the edges.

The practical real world solution is to sacrifice SFDR for simplicity and lower cost. The radio isn't quite as good, but it is the best one you can build. It has other areas where it blows the old analog beast out of the arena. It is only when you say that you want the best of all things all at the same time (possibly at a real low price as well) that the process goes "tilt".

I can live with those tradeoffs.

[cdev]

Ive never seen off the shelf (consumer) sound cards with more than a 192 KHz - (although I would not be surprised if they were out there, I just have never seen or used one)  and it seems that since the human ear only goes up to at the most 20 KHz, its unusual that they care what the passband is above that but still, many of them work okay, my sound card is a realtek onboard sound card and as I said I get a solid 170-180 KHz or so of BW with rolloff at the edges.

they do have filters for nyquist/antialiasing built in..or so I have read.

If sound cards were made for SDR use, they would be a lot more expensive because lower volume.

[Kalvin]

Unless you are using really wide modulation bandwidth there is not real reason or benefit to use direct RF sampling ADC and direct RF modulation with a DAC. Your sensitivity will be very poor if you are using a wideband receiver for receiving relative narrow band modulation.

Mixing to a relative narrow IF band and sampling this IF with an ADC, or using a zero IF architecture, will get the sensitivity as you can amplify the frequency in interest in order to maximize the dynamic range of your ADC. In similar fashion a transmitter can be created using a DAC to output relative narrow band IF signal which is then mixed to appropriate frequency.

Commutating detector ie. Tayloe detector is popular direct conversion architecture in SDR community. The commutating direct conversion architecture can also be reversed and used as a transmitter. Due to the practical component limitations, the commutating technique is usable up to 100MHz or so as the analog switches used in the detector need to switched at rate of 4 x frequency of interest. For example, listening for a FM radio at 100MHz, the switching frequency for the analog switches needs to be 400MHz. At higher switching frequencies the detected signal quality start suffering from the imperfections of the analog switches.

Using a transverter scheme, the direct conversion and direct IF sampling/modulation techniques can be used to create versatile and well performing transceivers.

[dkozel]

Hi Saber and folks.

Right out front, I work for Ettus Research and really like SDR.

Here's an example of an Amateur Radio operator who decided to do very similar to what you want to do. Ettus Research started off as a project to design a low cost, extensible software defined radio. The first radio was the USRP1 which was a motherboard with USB, an ADC/DAC, and an FPGA and a series of daughterboards for different frequency ranges with amplifiers, filters, and mixers.

The schematics are online here as well as two descriptions of the radio.

• http://files.ettus.com/schematics/usrp1/usrp1.pdf
• http://files.ettus.com/manual/page_usrp1.html
• http://www.faculty.ece.vt.edu/swe/chamrad/crdocs/CRTM09_060727_USRP.pdf

All the source code of the firmware, driver, and FPGA image are also available under the GPL license.

• https://github.com/ettusresearch/uhd

The USRP1 of course is basically entirely outdated at this point. There have been a bunch of radios released since then, the snazziest one receiving 120 MHz each from two daughterboards, tunable 10 MHz to 6 GHz. The schematics and source code are available at the links above.

Hopefully you don't take this as a sales pitch, just some resources for seeing what one group of people's designs look like for a broadband SDR. Let me know if you have any questions. GNU Radio is good fun to play with as well for experimenting with DSP.

There's a lot you can do with a broadband SDR without needing too much filtering, but it does certainly help! I have a stack of filters around my apartment which I swap in depending on my signal of interest. It helps deal with local FM broadcast, wifi interference, and my regular ham radio transmissions. Also knocks off the harmonics to keep me legal when transmitting.

The comments about high speed ADC/DACs being expensive is dead on, they contribute highly to the cost of a nice SDR. The USRPs range in cost but can be as much as some HF basestations, though not as much as some of the crazy expensive contesting ones. Of course you also don't get power amplifiers and the knobs and buttons.

The BladeRF is another open hardware SDR worth taking a look at for some inspiration. At a block design level it's very similar to Ettus' B200 but uses a different RF frontend.

• https://nuand.com/bladerf.pdf

The Elecraft radios are heavily DSP based and their schematics are available here. The K3 and KX3 are nice designs and have all the traditional knobs. I'd love to drive one of these sometime. A fantasy of mine for a while has been to reverse engineer their protocol and make it a generic SDR control panel... one day

• http://www.elecraft.com/K2_Manual_Download_Page.htm#KX3

Cheers

[scatha]

Sounds like a fun job dkozel, Ettus makes some good gear and I really like the RFNoC architecture.

I've used the Ettus N210 with a BasicRX board in a few direct sampling receivers (mostly 138 MHz satcom), it's perfect because the analogue bandwidth of the ADCs (~500 MHz) is much greater than the ADC sample rate (100 MHz). This means that you can use sub-nyquist sampling to alias signals up to 500 MHz down to a more reasonable IF, no mixers required. You just need to supply the external filtering (BP cavity filter to combat the high-level VHF radio interferers) and LNA.

[ConKbot]

Here we go..  more bits, less bucks.. Just get a better sound card.. You may already have one.

QSD is inherently also a good band pass filter!  This is what Flexradio and Softrock and a lot of other quite economical quite good SDRs use. It really works well. Its like a rotary switch, click click click click.

http://www.google.com/search?q=quadrature+sampling+detector

http://www.google.com/search?q=tayloe+mixer

So your sound card is your ADC. And thats around the cheapest high quality ADC you are going to find anywhere and it works in the low frequency domain so the QSD converts your signals to that.  I and Q.

Agreed, it works well enough in SDRs that adc for the bw and dynamic range needed won't break the bank. But that's not what the ts asked for.

   The whole idea behind this is to filter and amplify your RF signal, and then directly sample the RF signal via the ADC, and everything leaving the DSP would exit through a DAC. All further processing (IF mixing, filtering, modulation, demodulation) is done digitally.

Rf in -> amp -> ADC.   With a rather impressive preselector that will go from 0-500MHz.

The usual trend of people being scared of RF and wanting to push all the scary bits into software.

[DimitriP]

Have anyone here ever done something similar to this? Experimental/commercial/professional, I don't care. If you have any guidance, input, or ideas as far as is possible on component selection, possible architectures.

Not over here,  but this guy did it over there:



http://www.adat.ch/index_e.html

[cdev]

It would be great if somebody were to implement a traditional all band transceiver in software, in the form of a GnuRadio flowgraph.

And maintain it. Then people could buy a USRP or similar radio for use as a ham radio transceiver. (Please correct me if somebody has already done this!)

Personally, I am most interested in SDR in the context of ham radio.  And I see SDR as being inherently much more likely to be affordable than analog radios because the approach leverages computers.

There are probably thousands of people like me, introduced to SDR by the RTLSDRs, who would be a ready made market for exceptional value transmit capable SDRs that had decent enough software support - enabling their use in amateur radio.

We are not potential Yaesu or Kenwood or Elecraft even owners, with >$1000s to spend.

We are not going to spend thousands of dollars on a radio. Certainly not a non-SDR radio or an SDR-cum-computer-in-an-expensive-box.

As the hardware can be made and perform well at low cost, there is a market for good value and people know it when they see it.  Companies need to recognize that need and fill it better. I think most people are looking for hardware that isnt going to lock them into an overpriced ecosystem, they want hardware that they can expand themselves, that is supported by existing, fairly mature software tools.

That could come via the already fairly substantial softrock compatible (Si570) route. Which works well, despite some issues related to the sound cards. People can solve that problem by buying a better one thats external to their computer. Some of the radios that use that architecture basically have a USb audio device built into them. That seems like a good approach that is likely to be fairly cheap too. It seems that done right, sampling 24 bits at 192KHz will give excellent performance. On a par with the best analog radios on the market. Its my understanding that a few more db can be gotten by using a slightly higher supply voltage than 5 volts. 12 volts is ideal.

It appears the Softrock Ensemble RxTx is quite good - better than many people seem to think, when configured properly, especially considering its price. 

There are also now HPSDR compatible boards, like Hermes-Lite, which looks quite promising.

The other option is to go into gnuradio-capable SDR hardware and adapt existing software to make a SDR transceiver. I don't see any reason why that can't be done, maybe it has been done?

Lots of people would be very happy, if it was possible to use their existing USRP, HackRF, BladeRF, (and now Red Pitaya?) hardware for amateur radio.

That would encourage a lot of experimentation in the UHF bands, I am sure.

There are now enough people who have gnuradio capable hardware to support a growing ecosystem of software for other applications, similar benefits would come to amateur radio, I am sure.

That would be a logical route that would leverage lots of existing hardware and knowledge.

As far as having knobs, LCD displays and so on, there are libraries that allow using COTS encoder-containing hardware as digital controls for SDRs.

It seems as if a lot of people do this with the Hercules brand of DJ controllers

So now with all these options I think that the person who wants a really great performing HF setup who wants to build one themselves likely can do it without a lot of fuss if they are willing to take it slowly and listen to expert advice when they don't know what to do.  Radios like the Softrock series and the various related projects are affordable and a good entry point that wont break the bank.

I think also there are lots of hams (and aspiring hams such as myself) who likely would prefer a built radio but dont want to pay >$1000 for a rig that they likely could build themselves for maybe $200 or a bit more. (Using the softrock kits or other si570 based SDRs, or something like Hermes-Lite as the starting point)

A vendor that designs their product with care can likely make a solid product that sells for $400 or less that has all the bells and whistles apart from high power. A switchable rig which could output >1 watt or 50 watts a power level that would drive most HF amps - simplifying the upgrade path. would make economic sense for people, especially if it was self contained enough to be used when traveling with a laptop, and USB headset or usb audio dongle to provide the mike input. That way the computer's capabilities are used to the greatest level keeping the cost down.

The excuse that mass production isnt available for HF gear in the same way just doesnt cut it.  A vendor who is willing to deliver a quality product for less likely would have doors opened for them, because nobody wants to see a great hobby die because younger people who want to- cannot afford to enter it.

[AF6LJ]

It would be great if somebody were to implement a traditional all band transceiver in software, in the form of a GnuRadio flowgraph.

And maintain it. Then people could buy a USRP or similar radio for use as a ham radio transceiver. (Please correct me if somebody has already done this!)

Personally, I am most interested in SDR in the context of ham radio.  And I see SDR as being inherently much more likely to be affordable than analog radios because the approach leverages computers.

There are probably thousands of people like me, introduced to SDR by the RTLSDRs, who would be a ready made market for exceptional value transmit capable SDRs that had decent enough software support - enabling their use in amateur radio.

You get what you pay for, the RTLXX series radios are for the most part junk.

We are not potential Yaesu or Kenwood or Elecraft even owners, with >$1000s to spend.

We are not going to spend thousands of dollars on a radio. Certainly not a non-SDR radio or an SDR-cum-computer-in-an-expensive-box.

Given the rate of inflation $2,000.00 for a good all mode HF radio is a good value considering the five band radios of the seventies ran around $500.00 or more, that was forty years ago.

As the hardware can be made and perform well at low cost, there is a market for good value and people know it when they see it.  Companies need to recognize that need and fill it better. I think most people are looking for hardware that isnt going to lock them into an overpriced ecosystem, they want hardware that they can expand themselves, that is supported by existing, fairly mature software tools.

I disagree;
The hardware cannot be made cheaply due to the cost of indivudal parts themselves.
RF transistors for power amplifiers are not cheap, someone has to design a heatsink for a PA output filters must be designed and built not to mention the rest of the labor that goes into building the rest of the radio, not all of it will be surface mount parts.
Who is going to pay for type acceptance in the US let alone other countries?
See Part 97.307-317  All of this costs money and that cost must be rolled into a completed transceiver.

That could come via the already fairly substantial softrock compatible (Si570) route. Which works well, despite some issues related to the sound cards. People can solve that problem by buying a better one thats external to their computer. Some of the radios that use that architecture basically have a USb audio device built into them. That seems like a good approach that is likely to be fairly cheap too. It seems that done right, sampling 24 bits at 192KHz will give excellent performance. On a par with the best analog radios on the market. Its my understanding that a few more db can be gotten by using a slightly higher supply voltage than 5 volts. 12 volts is ideal.

It appears the Softrock Ensemble RxTx is quite good - better than many people seem to think, when configured properly, especially considering its price. 

I have experience with softrock radios and find the receiver performance less than acceptable.
1.5 microvolt sensitivity is rather poor, even for the low bands. They are nice toys.

There are also now HPSDR compatible boards, like Hermes-Lite, which looks quite promising.

The other option is to go into gnuradio-capable SDR hardware and adapt existing software to make a SDR transceiver. I don't see any reason why that can't be done, maybe it has been done?

Lots of people would be very happy, if it was possible to use their existing USRP, HackRF, BladeRF, (and now Red Pitaya?) hardware for amateur radio.

That would encourage a lot of experimentation in the UHF bands, I am sure.

There are now enough people who have gnuradio capable hardware to support a growing ecosystem of software for other applications, similar benefits would come to amateur radio, I am sure.

That would be a logical route that would leverage lots of existing hardware and knowledge.

As far as having knobs, LCD displays and so on, there are libraries that allow using COTS encoder-containing hardware as digital controls for SDRs.

It seems as if a lot of people do this with the Hercules brand of DJ controllers

So now with all these options I think that the person who wants a really great performing HF setup who wants to build one themselves likely can do it without a lot of fuss if they are willing to take it slowly and listen to expert advice when they don't know what to do.  Radios like the Softrock series and the various related projects are affordable and a good entry point that wont break the bank.

I think also there are lots of hams (and aspiring hams such as myself) who likely would prefer a built radio but dont want to pay >$1000 for a rig that they likely could build themselves for maybe $200 or a bit more. (Using the softrock kits or other si570 based SDRs, or something like Hermes-Lite as the starting point)

A vendor that designs their product with care can likely make a solid product that sells for $400 or less that has all the bells and whistles apart from high power. A switchable rig which could output >1 watt or 50 watts a power level that would drive most HF amps - simplifying the upgrade path. would make economic sense for people, especially if it was self contained enough to be used when traveling with a laptop, and USB headset or usb audio dongle to provide the mike input. That way the computer's capabilities are used to the greatest level keeping the cost down.

The excuse that mass production isnt available for HF gear in the same way just doesnt cut it.  A vendor who is willing to deliver a quality product for less likely would have doors opened for them, because nobody wants to see a great hobby die because younger people who want to- cannot afford to enter it.

The biggest issue many such as myself have with SDR is the need for an external computer, along with the lack of easy to use controls (knobs etc...)
Put it all in one box and add knobs and a display and you have a real radio.
Something like this, and it is in my price range.
http://www.icomamerica.com/en/products/amateur/hf/7300/default.aspx
And it doesn't tie up my nice computer and 24 bit sound subsystem.

[cdev]

I've looked at that Icom. I agree, thats probably a better value than most.

It seems to be basically an SDR inside. Wonder if Icom has considered simply making an SDR without the additional wrapping? To save money.

-----

Its my understanding that the raw sensitivity figure on HF is not a good measure of performance because of the inherent noise level. Sensitivity of a HF receiver needs to be good enough to pick up the inherent noise and a bit more but it doesn't need to be better than that.

The newer Softrock Rx comes with a 10 db low noise amplifier for 16 MHz and above.

Adding more gain is not going to improve reception on the lower HF bands.

Its my understanding that their Rx performance is quite good. Of course much much much better than the RTLs or similar, and even comparable with much more expensive modern or old style HF equipment.

Also, it seems that its possible to make the Tx performance in terms of spurious emissions quite good too, I am pretty sure this was done without adding additional filters. That is what I took away from watching the most recent YouTube videos by SM5BSZ. Maybe he was wrong, but it seems to me that he likely did know what he was talking about, watch the videos. (Since it was being discussed elsewhere, its also a good example of how somebody might sometimes need to use a bunch of oscilloscopes at the same time..)

The ensemble videos - are about the softrocks and the use of Linrad in transmit mode, and basically about spurious emissions, transmit receive switching/QSK, use of an inexpensive RxTx SR as Tx using various methods of carrier removal.

The radio he was testing I think costs $129. It only puts out a watt. So, one has to either amplify that or work with it. So, that adds substantial cost, I agree.

RF power amplifiers remain quite expensive, considering how much other things have fallen.

JFETs can be used to make inexpensive RF PAs that perform well enough to be useful. A sharp band pass filter is easy to make and seems likely to improve both Rx and Tx.

One can even make a preselector that does double duty as a BPF.

My point being that high performance, quite FCC-regulation compliant gear doesn't necessarily "have to be" expensive. 

If the complexity of ham gear adds so much to its cost and so much of that functionality is just as effectively implemented in software - why not?

People can add a rotary encoder by means of a cheap DJ controller and having it horizontal on the desk, especially if you can spin the knob by means of a detent for your fingertip, is arguably more ergonomic than having it on the front panel of a standalone radio.

Having an SDR potentially clears up a lot of space on a desk so people can have more test equipment there.

Lots and lots more young people would enter the hobby if there were better options on the entry level for gear, and SDR is the only way to make that gear fun, modern and affordable, IMHO.

[uncle_bob]

Hi

A real world RF PA needs to withstand a *lot* of abuse. The level of care required in the design is pretty demanding. The kind of testing you *should* do it not simple. A lot of what you see tossed around are amps designed to run into something other than a randomly chosen antenna. In a ham setting, the designer has no control over what sort of load impedances may be present when the radio is keyed up. Tuners are wonderful things, they go bad, they look like a really strange load while tuning. They also only match at one frequency. The amp still needs to be stable at *all* frequencies ....(with any load).

People build these things every day. It's not rocket science. The parts are out there. The information you need to learn is out there. Setting up to do it and doing it right do take some effort. Trying to do 1.5 MHz to 500 MHz with a single amp ... that's going to be exciting. It's far more typical to break things into a few bands in this case.

If your target is a "full blown radio", it needs to have a reasonable PA that puts out a few hundred watts. Otherwise, you are just selling part of a radio. The customer still needs to buy a bunch of other stuff to get a reasonable setup. That's not a lot different than buying a computer, a SDR receiver, a SDR transmitter and a bunch of cables ....

Bob

[AF6LJ]

I've looked at that Icom. I agree, thats probably a better value than most.

It seems to be basically an SDR inside. Wonder if Icom has considered simply making an SDR without the additional wrapping? To save money.

-----

Its my understanding that the raw sensitivity figure on HF is not a good measure of performance because of the inherent noise level. Sensitivity of a HF receiver needs to be good enough to pick up the inherent noise and a bit more but it doesn't need to be better than that.

The newer Softrock Rx comes with a 10 db low noise amplifier for 16 MHz and above.

Adding more gain is not going to improve reception on the lower HF bands.

Its my understanding that their Rx performance is quite good. Of course much much much better than the RTLs or similar, and even comparable with much more expensive modern or old style HF equipment.

Also, it seems that its possible to make the Tx performance in terms of spurious emissions quite good too, I am pretty sure this was done without adding additional filters. That is what I took away from watching the most recent YouTube videos by SM5BSZ. Maybe he was wrong, but it seems to me that he likely did know what he was talking about, watch the videos. (Since it was being discussed elsewhere, its also a good example of how somebody might sometimes need to use a bunch of oscilloscopes at the same time..)

The ensemble videos - are about the softrocks and the use of Linrad in transmit mode, and basically about spurious emissions, transmit receive switching/QSK, use of an inexpensive RxTx SR as Tx using various methods of carrier removal.

The radio he was testing I think costs $129. It only puts out a watt. So, one has to either amplify that or work with it. So, that adds substantial cost, I agree.

RF power amplifiers remain quite expensive, considering how much other things have fallen.

JFETs can be used to make inexpensive RF PAs that perform well enough to be useful. A sharp band pass filter is easy to make and seems likely to improve both Rx and Tx.

One can even make a preselector that does double duty as a BPF.

My point being that high performance, quite FCC-regulation compliant gear doesn't necessarily "have to be" expensive. 

If the complexity of ham gear adds so much to its cost and so much of that functionality is just as effectively implemented in software - why not?

People can add a rotary encoder by means of a cheap DJ controller and having it horizontal on the desk, especially if you can spin the knob by means of a detent for your fingertip, is arguably more ergonomic than having it on the front panel of a standalone radio.

Having an SDR potentially clears up a lot of space on a desk so people can have more test equipment there.

Lots and lots more young people would enter the hobby if there were better options on the entry level for gear, and SDR is the only way to make that gear fun, modern and affordable, IMHO.

Having a fair amount of gear to compare the Softrock to and being active on 40 and 75 I can tell you there are plenty of signals the Softrock doesn't hear that my IC-745, Swan-500CX, Heathkit twins (SB-401 / SB-303), my Kenwood TS-820 and other radios at my station hear with little to no trouble.

I would add;
The amateur radio community at large isn't interested in SDR gear that is bound to a computer. The gear isn't very "portable".

[cdev]

Has anybody here ever used or does anybody here own one of those DJ controllers (Hercules is the brand that seems to have the most support) with SDRs?

[AF6LJ]

Its really a matter of personal taste as far as whether people want to have a big radio with knobs or  a small radio they use with a computer.

Or don't care *that* much either way, 'as long as it works'.

Now with the quad core ARM based Raspberry Pi 2, Odroid, etc, there is no reason people cannot use an embedded PC as their 'radio' and I am sure that a small PC with SDR functionality will come along some day.. (even if it doesn't contain the actual SDR, you have to buy one separately, or build one yourself)

In a word Agreed....

[cdev]

Sue, you bring up a good point about portable operations and the thing that really stands out there is emergency operations. How robust are SDRs compared to non-SDRs in a portable setting, there I think the conventional radios still come out way ahead.

On the other hand, in any power constrained environment, digital modes have the potential of doing a lot more communications per watt than conventional radios, if the users can either live with text being whats sent or use something like codec2 that performs real data compression magic by turning audio into a much smaller amount of bits and bytes than usual, and turning it back into intelligible audio on the other end.

Actually, I think that the need to use mega power amps likely could be phased out using digital modes in such a way.

Over time. because these systems when optimized may I suspect at some point make up in smarts what they lose in power.

Like for example, with a softrock, the performance drastically changes depending on the sound card and how much noise is being picked up and the little things about the audio chain that oftentimes can drastically change by, say, turning off some extra inputs that you didnt realize were live, suddenly you might have 20 db more headroom because of some little hum or hiss you could barely hear. Or on the high side, some drivers just zap, result in you losing 10 db or more dynamic range and thats just a mistake that comes along with using some setting and for most sound using apps it matters not a bit, but with SDR it makes all the difference in the world. The same thing with grounding your computer and your SDR together.. If your SDR's performace isnt so great, in your experience, I would look there first.

I do know with the SR, since it uses a 12 volt supply, I think there is actually a reason for that in that the top output of the radio is basically - like with the feeltech function generator, limited by the voltage on the power rail.. You're only going to get the full dynamic range if the input you have it plugged into has its level optimized for what its getting and also is using the full 24 bits and not just 16. if you are only using 16, try using the full 24 if your sound card has that, you may be surprised!

[uncle_bob]

Sue, you bring up a good point about portable operations and the thing that really stands out there is emergency operations. How robust are SDRs compared to non-SDRs in a portable setting, there I think the conventional radios still come out way ahead.

Hi

I think that it is very much a "that depends" sort of thing.

Most emergency operation is a very disciplined net based setup. If you are net control, you spend a lot of time on the air. Pretty much everybody else spends a lot of time listening and logging information. In many ways a packet radio setup would do this well. In many cases the packet nets are more difficult to set up than their voice equivalents.

With a voice system, you probably will need something to take notes. Most of us do that on computers. With a packet system, the computer is an obvious way to go. Once the computer is there, a USB based SDR works pretty well. Small SDR plus computer likely is easier to transport than a larger radio or set of radios. A "no display / no knobs" radio has a lot less to go wrong with it. Mine have been quite reliable. Once you get to a half dozen boxes, twenty cables, three antennas and power .... that's a mess. You have gone well past a backpack and maybe past what will fit in the car. Consider that you might also want to have food, water, socks, and a sleeping bag ...

Bob

[dkozel]

Hi Scatha, Thanks! It's a fun environment to be part of and a great group of people to be learning from.

Unfortunately SDRs face tradeoffs between price, quality, and complexity just like any other system. The AD9364 transceiver for instance has 61.44 MSPS dual channel ADC and DACs in it, along with local oscillators and mixers allowing direct conversion from 50 MHz to 6 GHz. This means your RF frontend is basically just one chip and a tiny bit of matching. But it costs $156 in 1500 quantity from Digikey. Sure, the price would go down some probably if a company negotiated huge orders, but I doubt that it would be that much less. Then there's still an FPGA, basically necessary as glue between whatever the connection with the host computer is and the raw sample streams coming to and from the frontend. 61.44M * 2 channels * 12 bit samples = 184 MB per second, almost a gigabit of data per second! Certainly something modern tech can handle, but a lot of data to move around none the less. Even a small FPGA adds a decent amount to the cost. Then there's whatever the radio's connection to the host computer is. If you integrate everything into one board then that can be free, but most systems use USB, Ethernet, or PCIe. Larger FPGAs can have these integrated which is nice.

The above doesn't count filters or amplifiers either. A 50 or 100 W amplifier requires input and output filtering to get good performance and LNAs are needed on the receive side to get good sensitivity and keep the total noise figure low. Without preselector filters that a high power local AM station, or other high power transmitters, will desensitize a wideband receiver.



The ADAT-200A is really interesting to be sure. Built in predistortion and a really nice frequency reference! It would be interesting to be able to learn more about the processing algorithms in use for speech processing and other baseband operations. A pity it's $3,750ish.

SoDaRadio is a project which uses SDRs for microwave Amateur operation. I look forward to trying it sometime soon.

• http://sodaradio.sourceforge.net/Site/SoDaRadio.html

Here's a fun example of a laptop which can have an SDR attached directly.

• https://myriadrf.org/blog/sdr-enabling-the-novena-open-hardware-laptop/

As for portable operation, there's not anything stopping an SDR from being rugged. There are a number of military radios which use SDR techniques for their baseband and in the end it's just hardware.

The Whitebox is an effort to make an SDR handheld transceiver. I had a chance to talk with it's creator at the ARRL Pacificon two years ago.

• http://radio.testa.co

Sorry, I can't keep up with the pace of the thread so I'm sure I'm missing on stuff. There's often Amateur radio activity on the GNU Radio mailing list, anyone interested in SDR I'd highly encourage installing GNU Radio and playing around with it. You can route the audio from your standard basestation through your computer and play with adding filters or implementing any of the many various "soundcard" digital modes quite easily. I read the list daily and would love to lend a hand getting anyone started.

I do very much hope that a modular SDR radio gets produced sometime. I think a PXI chassis or Phonebloks/Project Ara style modular design would be a great architecture. The processing capabilities of processors and fpgas, performance of amplifiers, and speed of ADCs and DACs increase so rapidly that creating a monolithic design seems like a path to quick obsolescence. But knobs! and buttons. Decent UI! The front panel design of a basestation has been refined quite nicely. Adding a high resolution display and video out to a large monitor would allow for many of the advanced features that SDR techniques can provide to be used.

For what it's worth, I went with a Kenwood TS-590s for my HF station largely due to it's USB interface. It's very nice to have easy digital access to the rx and tx audio. I do wish they had a provision for sending raw IQ samples though given they are doing the baseband processing all in DSP.

[dmills]

The problem is that to a large extent the small signal RF bit is a solved problem once you get behind the input BPF, but if you want good performance that input filter stage is still more then a little large, as you want to limit the bandwidth at the ADC.

It is interesting to note that you can leverage subsampling to allow an ADC  going at maybe 120MHz to sample HF-6M, 2M & 70cm, as long as the input filters are sufficiently narrow and have sufficient stopband.

Power amplifiers are interesting, and the HAM stuff tends to ignore some of the possibilities, envelope tracking for example makes things run cooler, or on 2M, 70cm, maybe a Doherty design (The 90 degree phasing lines become reasonable), possibly with cartesian feedback to allow the things to run closer to saturation?

Costs are actually largely in things that are in some sense peripheral, NRE costs, Certification, pretty front panels, power amplifiers, heatsinks and other metalwork, none of which are made simpler.

Regards, Dan.

[cdev]

Making a radio in a plain black box with the user using off the shelf mass produced devices like DJ consoles perhaps to provide application appropriate control surfaces..same thing with RF amplifiers, maybe building their own amp, seems like a good way to keep the costs reasonable.

Modular makes sense as it keeps the entry cost low and everybody likes to do things a bit differently.

Hardware elements like band pass filters are easy to build, so people might often want to do that themselves.

If they didnt already have other test equipment, since RTLs do have adequate dynamic range to do so (just barely) they could likely be used for testing the (HF filters) with a Raspberry Pi (siggen)/RTLSDR (direct sampling receiver) setup that could be made for under $55-60  (with sharp filters to ensure that it was accurate)

Low power/receive only filters only cost pennies so they can be used economically in a setup to test beefier transmit-capable filters.

Maybe ham clubs could also host a QRP DIY rig testing day every few months where builders could get some hard numbers on how clean they were before putting them on the air. (People could also test their store bought hardware.)

I think I have around 2/3 to 3/4 of what I would need for a QRP SSB HF rig now, it sure would be nice to have support from the ham community for *responsible* DIYing.

The #1 issue as I see it is ensuring that home built hardware puts out a clean signal when it transmits.

By making knowledge and testing accessible and affordable, everybody benefits.

More hams enter the hobby, and eventually, probably sooner rather than later, they likely will buy mainstream SDR or conventional hardware.

[Kalvin]

I had a discussion today with a friend of mine about SDR radios and he pointed me towards the http://www.m0nka.co.uk/ Look pretty nice multimode/multiband transceiver for the 3 - 30MHz ham bands. It is open source hardware and software, plus a kit is also available. The design is a good example of a simple yet complete  direct conversion transceiver. As it is open source, it is very suitable for hacking, too.

Edit: The design uses a temperature sensor to measure the Si570 oscillator temperature and the software will perform fine tuning according to the measured temperature. One could also provide a heater element to the Si570 which would use the use the temperature sensor to keep the device in constant temperature, so there would be a need for temperature dependent fine tuning. Another solution would be to use a precision TCXO with the CPU's timer by connecting the Si570's output through a prescaler to the CPU timer, use the CPU as a frequency counter, and let the software fine tune the Si570 - No need for temperature sensor. Using the temperature sensor will reduce the power consumption a bit, though.

[uncle_bob]

Hi

If you dig into the TAPPR stuff, they have been down the road with a modular software defined radio system. Lots of boards. Lots of backplanes. Many bits and pieces. It never has turned into a full blown rig with a front panel like an Icom. They have had a pretty good sized herd of people pouring work into the various designs for a couple of decades.

One major question is "what are the features?". A Si570 is a great part for a simple quick radio. The performance you get out of it is not going to compete with a full blown radio if you look at a number of specs. Is that important? How good does the product need to be? Change the goals and you *do* impact the task of designing and building the radio.

You can get a pretty good USB based SDR in the ~ $1K range. You will have a computer hooked up for sure. You will have a "mili watts" level output. The radio will not make it to 100 MHz.  It may be a multi box arrangement, a lot depends on what you buy. You can easily spend 2X that amount as well.

Bob

[Kalvin]

A simple SDR (like mcHF mentioned above) combined with a simple transverter http://lea.hamradio.si/~s53mv/zifssb/block.html could provide best of the both worlds: A traditional design for the high frequency path (up to few gigahertz) and digital design for the baseband. The system requires a simple front end for each band, but the baseband with the user interface and signal processing can be shared with the front ends.

[cdev]

It seems the si570 has spawned what seems like dozens of ham transceiver and receiver projects. They do seem remarkably stable, as far as I can tell. There are some quirks too.

Maybe the quirks make them not as much of a beginners project as many others.

I wonder what percentage of people who start with a given SDR project finish? It probably varies a lot, with some communities being much more knowledgeable than others.

Some projects are based on parts that may not be around in the future, that's also somewhat of a cause for concern.

Thinking about all this, maybe the people who are skeptical about the DIY path are right, it certainly is a challenge that's likely to be quite daunting to build one's station yourself.

[C]

I think that a lot of people forget,
It's not a Radio Receiver,
It is a Radio Receiver System!
In the real world you do not know what you are missing until someone or some other equipment shows what you are missing in a lot of cases.

Each change in a system has it's good points and it's bad points. A system is only as good as it's weakest part.

For example think of what a Preamp does. While it is boosting the weak signals by x db it is also boosting all the signals it sees at it's input by x db. With a wide band RF input that can be a huge problem.
The preamp output goes to the RF input. Where Is the agc for the RF input stage coming from? 
Here is a case where direct digital sample could make it easer where the other choice is to use the mixer output for an example. Using mixer output to do AGC also means that the IF amplifier also gets less signal to work with. Using the narrow band width of the IF amplifier output = missing some strong signals at the mixer input causing mixer overload.
Two choices, do it right or hope it does not happen.
The third choice is manual switching in and out the preamp is not great idea in a lot of real world cases.
And this is leaving out the other changes that a preamp creates.
And this is just one small part of the total.

It's a Radio Receiver System.

[uncle_bob]

A simple SDR (like mcHF mentioned above) combined with a simple transverter http://lea.hamradio.si/~s53mv/zifssb/block.html could provide best of the both worlds: A traditional design for the high frequency path (up to few gigahertz) and digital design for the baseband. The system requires a simple front end for each band, but the baseband with the user interface and signal processing can be shared with the front ends.

Hi

The gotcha there is that you get all of the nasty issues from the analog world *and* the nasty stuff from the digital world. You need a very clean synthesizer rather than a clean fixed frequency clock. The low noise clock might be $100, the synthesizer (for the same -160 to -170 dbc/Hz phase noise) could easily be 10X that.  Is a Si571 ok with phase at -120 to -140 dbc/Hz ok for what you are doing? Maybe you notice the (might be) 50 db of lost dynamic range, maybe other things are more important (or mask it).

At some point, you have no choice at all but to down convert. You simply can not get X band 12 bit DAC's or ADC's. The answer is a downconverter (plus up-converter if you are transmitting). At that point you design the best thing you can and move on.

Bob

[Nuno_pt]

For an SDR inside one box till 148MHz you can see the MB1 radio from sunsdr < http://sunsdr.eu/product/mb1/ >, it,s not cheap at 6000€.

[cdev]

Listening to the capture files people have captured with SDRs is often helpful/interesting.

[Howardlong]

Sorry, only just seen this thread. As an academic exercise, I built an AM receiver with a microcontroller, RF into the MCU's ADC and demodulated AM out.

True, you could do the same thing with a diode, coil and cap, but like Everest, mountains are there to climb.

I did a video about it. Hopefully some of the concepts, particularly the filtering and mixing in the digital domain, will show that computationally currently it's far from trivial to offer direct DC to 500MHz input bandwidth: this was for 500kHz to 1.5Mhz, with the latter half undersampled. Typically you'll need ASICs like DDCs and FPGAs to achieve much higher frequencies and bandwidths purely in the digital domain.

If you can compromise your desire for pure digital, it's still far cheaper to do you down/up conversion in the analogue domain and accept/correct any aberrations as necessary in software.

[Kalvin]

Nice video, Howardlong!

I bumped to this M4 + FPU core benchmark: https://community.freescale.com/thread/327833 According to this benchmark, the Q15-arithmetic is somewhat more efficient compared to the floating point operations, although the floating points results are pretty impressive. The floating point MAC will require 3 cycles compared to Q15 single cycle MAC operation (see: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/BEHICJFB.html). FPU is very handy, but in order to squeeze the optimal performance the Q15 seems to offer an advantage.

There is a new algorithm by Martin Vicanek for a recursive quadrature oscillator that you may find interesting:
http://vicanek.de/articles/QuadOsc.pdf
Related discussion at comp.dsp:
https://groups.google.com/forum/#!topic/comp.dsp/GFAzbora6bE

[Howardlong]

Nice video, Howardlong!

I bumped to this M4 + FPU core benchmark: https://community.freescale.com/thread/327833 According to this benchmark, the Q15-arithmetic is somewhat more efficient compared to the floating point operations, although the floating points results are pretty impressive. The floating point MAC will require 3 cycles compared to Q15 single cycle MAC operation (see: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/BEHICJFB.html). FPU is very handy, but in order to squeeze the optimal performance the Q15 seems to offer an advantage.

There is a new algorithm by Martin Vicanek for a recursive quadrature oscillator that you may find interesting:
http://vicanek.de/articles/QuadOsc.pdf
Related discussion at comp.dsp:
https://groups.google.com/forum/#!topic/comp.dsp/GFAzbora6bE

That code was -seriously- hand optimised assembly over a period of a few days. As well as getting the right algorithm, it's not just about how many cycles, it's also about minimising stalls with instruction interleaving, minimising memory accesses, and how many registers you have on an archtecture like ARM. There are 32 floating point registers but only 13 general purpose integer registers. All floating point operations ended up single cycle with judicious interleaving and loop unrolling: MACs are just one small piece of the jigsaw. I seriously doubt you could do much, if any, improvement with integer only due to he increased need to hit memory down to lack of registers, and I did spend some time on exactly that. Having 32 FP registers is the deal clincher, it means your memory accesses are minimised and that's what ARM is all about.

If you tried to do the pinch points in C, even using idioms, loop unrolling and builtins, zero wait state memeory, it just wouldn't work, not by quite a way. The CMSIS DSP library was useless for this by the way, it does not implement decimation with polyphase filters so is quite inefficient as a result.

[Howardlong]

Here's a snippet for the NCO and downconversion. By amalgamating the two, unrolling the loop by 8 and interleaving mutually exclusive operations, it means that memory accesses can be minimised. Note the use of .balign 4: this is to stop 32 bit instructions straddling words, which significantly affects performance. All floating point ops are 32 bit. Also note the use of carefully selected registers and adjacent store and load multiple to minimise cycles.

Code: [Select]

typedef float32_t SAMPLETYPE;
typedef float32_t COEFFTYPE;

typedef struct
{
SAMPLETYPE stI;
SAMPLETYPE stQ;
SAMPLETYPE stA;
SAMPLETYPE stB;
} NCOSTRUCT;

NCOSTRUCT _ncos;

COMPLEXSTRUCT _acsIn[NUM_SAMPLES];
COMPLEXSTRUCT _acsOut[NUM_SAMPLES*INT_FACTOR/DEC_FACTOR];

static void NCOInit(NCOSTRUCT *pncos,SAMPLETYPE stSampleRate,SAMPLETYPE stFreq)
{
pncos->stA=(SAMPLETYPE)cos(2.0*PI*stFreq/stSampleRate);
pncos->stB=(SAMPLETYPE)sin(2.0*PI*stFreq/stSampleRate);
pncos->stI=(SAMPLETYPE)1.0;
pncos->stQ=(SAMPLETYPE)0.0;
}

// How you'd do it if you didn't care about CPU, call this once for each sample pair to get the next NCO value.
__RAMFUNC(RAM2) static void NCONext(NCOSTRUCT *pncos,COMPLEXSTRUCT *pcs,int nNumSamples)
{
int i;

for (i=0;i<nNumSamples;i++)
{
SAMPLETYPE stTemp=pncos->stI;

pncos->stI = pncos->stA * stTemp - pncos->stB * pncos->stQ;
pncos->stQ = pncos->stB * stTemp + pncos->stA * pncos->stQ;

pcs[i].stI=pncos->stI;
pcs[i].stQ=pncos->stQ;
}
}

// This is the fast way to do it...
// Amalgamation of the NCO and downconvert function, unrolled by 8, call this every 4096 samples
__RAMFUNC(RAM2) static void DownConvert(NCOSTRUCT *pncos,uint32_t *pu32In,COMPLEXSTRUCT *pcsOut,int nNumSamples)
{
// This function prodcuces the quadrature NCO and complex mixes it with the RF (real) input
SAMPLETYPE stOffset=(SAMPLETYPE)1; // data comes in from ADC 0 to 4095, this is the offset used apply to move it to -1 to +1
SAMPLETYPE *pstOffset=&stOffset;

__asm__ __volatile__
(
"\n\t"
"vldm %[NCO],{s16-s19} \n\t" // Load NCO registers

"mov r6,%[NUMSAMPLES] \n\t"
"mov r5,r6,ASR #3 \n\t" // R5 is the division result for unrolling by 8
"and r6,r6,#7 \n\t" // R6 is the remainder, use to take the stragglers

"cbnz r5,loop1 \n\t"
"b loopexit1 \n\t"

".balign 4 \n\t"
"\nloop1: \n\t" // Do the unrolled version first

"vldm %[IN]!,{s24-s31} \n\t" // Load unsigned int samples
"vldm %[OFFSET],{s0} \n\t" // Reload 1.0 offset for 2's comp. conversion
"vcvt.f32.u32 s24,s24,11 \n\t" // Convert unsigned int to float
"vcvt.f32.u32 s25,s25,11 \n\t"
"vcvt.f32.u32 s26,s26,11 \n\t"
"vcvt.f32.u32 s27,s27,11 \n\t"
"vcvt.f32.u32 s28,s28,11 \n\t"
"vcvt.f32.u32 s29,s29,11 \n\t"
"vcvt.f32.u32 s30,s30,11 \n\t"
"vcvt.f32.u32 s31,s31,11 \n\t"
"vsub.f32 s24,s24,s0 \n\t" // Subtract 1 to make signed -1 to +1
"vsub.f32 s25,s25,s0 \n\t"
"vsub.f32 s26,s26,s0 \n\t"
"vsub.f32 s27,s27,s0 \n\t"
"vsub.f32 s28,s28,s0 \n\t"
"vsub.f32 s29,s29,s0 \n\t"
"vsub.f32 s30,s30,s0 \n\t"
"vsub.f32 s31,s31,s0 \n\t"

"vmul.f32 s20,s18,s16 \n\t" // 0.0 s20=A*I
"vmul.f32 s21,s19,s17 \n\t" // 0.1 s21=B*Q
"vmul.f32 s22,s19,s16 \n\t" // 0.3 s22=B*I
"vmul.f32 s23,s18,s17 \n\t" // 0.4 s23=A*Q
"vsub.f32 s16,s20,s21 \n\t" // 0.2 s16=A*I-B*Q
"vadd.f32 s17,s22,s23 \n\t" // 0.5 s17=B*I+A*Q
"vmul.f32 s0,s16,s24 \n\t" // 0.6 s0=I*In[0]
"vmul.f32 s1,s17,s24 \n\t" // 0.7 s1=Q*In[0]

"vmul.f32 s20,s18,s16 \n\t" // 1.0 s20=A*I
"vmul.f32 s21,s19,s17 \n\t" // 1.1 s21=B*Q
"vmul.f32 s22,s19,s16 \n\t" // 1.3 s22=B*I
"vmul.f32 s23,s18,s17 \n\t" // 1.4 s23=A*Q
"vsub.f32 s16,s20,s21 \n\t" // 1.2 s16=A*I-B*Q
"vadd.f32 s17,s22,s23 \n\t" // 1.5 s17=B*I+A*Q
"vmul.f32 s2,s16,s25 \n\t" // 1.6 s2=I*In[1]
"vmul.f32 s3,s17,s25 \n\t" // 1.7 s3=Q*In[1]

"vmul.f32 s20,s18,s16 \n\t" // 2.0 s22=A*I
"vmul.f32 s21,s19,s17 \n\t" // 2.1 s23=B*Q
"vmul.f32 s22,s19,s16 \n\t" // 2.3 s22=B*I
"vmul.f32 s23,s18,s17 \n\t" // 2.4 s23=A*Q
"vsub.f32 s16,s20,s21 \n\t" // 2.2 s16=A*I-B*Q
"vadd.f32 s17,s22,s23 \n\t" // 2.5 s17=B*I+A*Q
"vmul.f32 s4,s16,s26 \n\t" // 2.6 s4=I*In[2]
"vmul.f32 s5,s17,s26 \n\t" // 2.7 s5=Q*In[2]

"vmul.f32 s20,s18,s16 \n\t" // 3.0 s20=A*I
"vmul.f32 s21,s19,s17 \n\t" // 3.1 s21=B*Q
"vmul.f32 s22,s19,s16 \n\t" // 3.3 s22=B*I
"vmul.f32 s23,s18,s17 \n\t" // 3.4 s23=A*Q
"vsub.f32 s16,s20,s21 \n\t" // 3.2 s16=A*I-B*Q
"vadd.f32 s17,s22,s23 \n\t" // 3.5 s17=B*I+A*Q
"vmul.f32 s6,s16,s27 \n\t" // 3.6 s6=I*In[3]
"vmul.f32 s7,s17,s27 \n\t" // 3.7 s7=Q*In[3]

"vmul.f32 s20,s18,s16 \n\t" // 4.0 s20=A*I
"vmul.f32 s21,s19,s17 \n\t" // 4.1 s21=B*Q
"vmul.f32 s22,s19,s16 \n\t" // 4.3 s22=B*I
"vmul.f32 s23,s18,s17 \n\t" // 4.4 s23=A*Q
"vsub.f32 s16,s20,s21 \n\t" // 4.2 s16=A*I-B*Q
"vadd.f32 s17,s22,s23 \n\t" // 4.5 s17=B*I+A*Q
"vmul.f32 s8,s16,s28 \n\t" // 4.6 s8=I*In[4]
"vmul.f32 s9,s17,s28 \n\t" // 4.7 s9=Q*In[4]

"vmul.f32 s20,s18,s16 \n\t" // 5.0 s20=A*I
"vmul.f32 s21,s19,s17 \n\t" // 5.1 s21=B*Q
"vmul.f32 s22,s19,s16 \n\t" // 5.3 s22=B*I
"vmul.f32 s23,s18,s17 \n\t" // 5.4 s23=A*Q
"vsub.f32 s16,s20,s21 \n\t" // 5.2 s16=A*I-B*Q
"vadd.f32 s17,s22,s23 \n\t" // 5.5 s17=B*I+A*Q
"vmul.f32 s10,s16,s29 \n\t" // 5.6 s10=I*In[5]
"vmul.f32 s11,s17,s29 \n\t" // 5.7 s11=Q*In[5]

"vmul.f32 s20,s18,s16 \n\t" // 6.0 s20=A*I
"vmul.f32 s21,s19,s17 \n\t" // 6.1 s21=B*Q
"vmul.f32 s22,s19,s16 \n\t" // 6.3 s22=B*I
"vmul.f32 s23,s18,s17 \n\t" // 6.4 s23=A*Q
"vsub.f32 s16,s20,s21 \n\t" // 6.2 s16=A*I-B*Q
"vadd.f32 s17,s22,s23 \n\t" // 6.5 s17=B*I+A*Q
"vmul.f32 s12,s16,s30 \n\t" // 6.6 s12=I*In[6]
"vmul.f32 s13,s17,s30 \n\t" // 6.7 s13=Q*In[6]

"vmul.f32 s20,s18,s16 \n\t" // 7.0 s20=A*I
"vmul.f32 s21,s19,s17 \n\t" // 7.1 s21=B*Q
"vmul.f32 s22,s19,s16 \n\t" // 7.3 s22=B*I
"vmul.f32 s23,s18,s17 \n\t" // 7.4 s23=A*Q
"vsub.f32 s16,s20,s21 \n\t" // 7.2 s16=A*I-B*Q
"vadd.f32 s17,s22,s23 \n\t" // 7.5 s17=B*I+A*Q
"vmul.f32 s14,s16,s31 \n\t" // 7.6 s14=I*In[7]
"vmul.f32 s15,s17,s31 \n\t" // 7.7 s15=Q*In[7]

"vstm %[OUT]!,{s0-s15} \n\t" // Store complex downconverted version

"subs r5,#1 \n\t"
"bne loop1 \n\t"

"\nloopexit1: \n\t"

"cbz r6,loopexit2 \n\t"

".balign 4 \n\t"
"vldm %[OFFSET],{s0} \n\t" // Reload 1.0 offset for 2's comp. conversion
"\nloop2: \n\t" // This is for the straggler samples remaining from the unrolled version

"vldm %[IN]!,{s24} \n\t" // Load next sample
"vmul.f32 s20,s18,s16 \n\t" // s20=A*I
"vcvt.f32.u32 s24,s24,11 \n\t" // Convert unsigned int to float
"vmul.f32 s21,s19,s17 \n\t" // s21=B*Q
"vsub.f32 s24,s24,s0 \n\t" // Subtract 1 to make signed -1 to +1
"vmul.f32 s22,s19,s16 \n\t" // s22=B*I
"vmul.f32 s23,s18,s17 \n\t" // s23=A*Q
"vsub.f32 s16,s20,s21 \n\t" // I=A*I-B*Q
"vadd.f32 s17,s22,s23 \n\t" // Q=B*I-A*Q
"vmul.f32 s14,s16,s24 \n\t" // s14=I*In[0]
"vmul.f32 s15,s17,s24 \n\t" // s15=Q*In[0]

"vstm %[OUT]!,{s14-s15} \n\t" // Store complex downconverted version

"subs r6,#1 \n\t"
"bne loop2 \n\t"
"\nloopexit2: \n\t"

"vstm %[NCO],{s16-s17} \n\t"

: [OUT]"+r" (pcsOut), [NUMSAMPLES]"+r" (nNumSamples), [IN]"+r" (pu32In), [OFFSET]"+r" (pstOffset)
: [NCO]"r" (pncos)
: "r5","r6",
  "s0","s1", "s2", "s3", "s4", "s5", "s6", "s7", "s8", "s9",
  "s10", "s11", "s12", "s13", "s14", "s15", "s16", "s17", "s18", "s19",
  "s20", "s21", "s22", "s23", "s24", "s25", "s26", "s27", "s28", "s29",
  "s30","s31"
);
}

You also have to "trim" the NCO to stop it getting out of control over time, but this can be done occasionally and so has negligible performance impact.

Code: [Select]

    // Fix the NCO in case it's running away.
    // This is an approximation to G = 1/(SQRT(R^2+I^2)) =~ 0.5*(3-(R^2 + I^2))
stG=(SAMPLETYPE)0.5*((SAMPLETYPE)3.0-_ncos.stI*_ncos.stI-_ncos.stQ*_ncos.stQ);
_ncos.stI*=stG;
_ncos.stQ*=stG;


The downsampler:

Code: [Select]

#define NUM_SAMPLES 4096 // samples/block
#define NUM_COEFFS 1024 // number of FIR taps
#define INT_FACTOR 1 // Interpolations factor
#define DEC_FACTOR 128 // Decimation factor

#ifndef PI
#define PI 3.14159265358979
#endif

typedef float32_t SAMPLETYPE;
typedef float32_t COEFFTYPE;

#include "coeffs.h"

typedef struct
{
SAMPLETYPE stI;
SAMPLETYPE stQ;
} COMPLEXSTRUCT;

typedef struct
{
int nDecFactor;
int nIntFactor;
COEFFTYPE *pactCoeffsTransposed;
COMPLEXSTRUCT *pacsDelayLine;
COMPLEXSTRUCT *pcsDelayLineEnd;
int nPaddedCoeffCount;
int nCoeffsPerPhase;
int nCommutator;
int nXOffset;
} DOWNSAMPLESTRUCT;

static DOWNSAMPLESTRUCT _dss1;

// This is the optimised pinch point of the polyphase filter.
__RAMFUNC(RAM2)
static void DownSampleInner(COMPLEXSTRUCT *pcsIn,COMPLEXSTRUCT *pcsOut,COEFFTYPE **ppctCoeff,int nInCount)
{
COEFFTYPE *pctCoeff=*ppctCoeff;

__asm__ __volatile__
(
"\n\t"
"mov r5,%[INCOUNT],ASR #3 \n\t" //
"mov r6,%[INCOUNT] \n\t" // R6=number of full 8 unrolled iterations to do
"and r6,r6,#7 \n\t" // R6=remainder, ie any stragglers after unrolled loop

"vldm %[OUT],{s0-s1} \n\t" // Get the complex accumulator so far

"cbnz r5,loopRAI1 \n\t" // Check if enough samples for unroll by 8 version
"b loopexitRAI1 \n\t"

".balign 4 \n\t"
"\nloopRAI1: \n\t"

"vldm %[IN]!,{s16-s31} \n\t" // Load samples
"vldm %[COEFF]!,{s8-s15} \n\t" // Load coefficients

"vmul.f32 s2,s16,s8 \n\t" // s2=acsDelayLine[0].stI * *pctCoeff[0]
"vmul.f32 s3,s17,s8 \n\t" // s3=acsDelayLine[0].stQ * *pctCoeff[0]
"vadd.f32 s0,s0,s2 \n\t" // s0+=s2
"vadd.f32 s1,s1,s3 \n\t" // s2+=s3

"vmul.f32 s2,s18,s9 \n\t" // s2=acsDelayLine[1].stI * *pctCoeff[1]
"vmul.f32 s3,s19,s9 \n\t" // s3=acsDelayLine[1].stQ * *pctCoeff[1]
"vadd.f32 s0,s0,s2 \n\t" // s0+=s2
"vadd.f32 s1,s1,s3 \n\t" // s2+=s3

"vmul.f32 s2,s20,s10 \n\t" // s2=acsDelayLine[2].stI * *pctCoeff[2]
"vmul.f32 s3,s21,s10 \n\t" // s3=acsDelayLine[2].stQ * *pctCoeff[2]
"vadd.f32 s0,s0,s2 \n\t" // s0+=s2
"vadd.f32 s1,s1,s3 \n\t" // s1+=s3

"vmul.f32 s2,s22,s11 \n\t" // s2=acsDelayLine[3].stI * *pctCoeff[3]
"vmul.f32 s3,s23,s11 \n\t" // s3=acsDelayLine[3].stQ * *pctCoeff[3]
"vadd.f32 s0,s0,s2 \n\t" // s0+=s2
"vadd.f32 s1,s1,s3 \n\t" // s1+=s3

"vmul.f32 s2,s24,s12 \n\t" // s2=acsDelayLine[4].stI * *pctCoeff[4]
"vmul.f32 s3,s25,s12 \n\t" // s3=acsDelayLine[4].stQ * *pctCoeff[4]
"vadd.f32 s0,s0,s2 \n\t" // s0+=s2
"vadd.f32 s1,s1,s3 \n\t" // s1+=s3

"vmul.f32 s2,s26,s13 \n\t" // s2=acsDelayLine[5].stI * *pctCoeff[5]
"vmul.f32 s3,s27,s13 \n\t" // s3=acsDelayLine[5].stQ * *pctCoeff[5]
"vadd.f32 s0,s0,s2 \n\t" // s0+=s2
"vadd.f32 s1,s1,s3 \n\t" // s1+=s3

"vmul.f32 s2,s28,s14 \n\t" // s2=acsDelayLine[6].stI * *pctCoeff[6]
"vmul.f32 s3,s29,s14 \n\t" // s3=acsDelayLine[6].stQ * *pctCoeff[6]
"vadd.f32 s0,s0,s2 \n\t" // s0+=s2
"vadd.f32 s1,s1,s3 \n\t" // s1+=s3

"vmul.f32 s2,s30,s15 \n\t" // s2=acsDelayLine[7].stI * *pctCoeff[7]
"vmul.f32 s3,s31,s15 \n\t" // s3=acsDelayLine[7].stQ * *pctCoeff[7]
"vadd.f32 s0,s0,s2 \n\t" // s0+=s2
"vadd.f32 s1,s1,s3 \n\t" // s1+=s3

"subs r5,#1 \n\t"
"bne loopRAI1 \n\t"

"\nloopexitRAI1: \n\t"

"cbz r6,loopexitRAI2 \n\t"

".balign 4 \n\t"
"\nloopRAI2: \n\t" // Do the stragglers

"vldm %[IN]!,{s16-s17} \n\t" // Load sample
"vldm %[COEFF]!,{s8} \n\t" // Load coefficient

"vmul.f32 s2,s16,s8 \n\t" // s2=acsDelayLine[0].stI * *pctCoeff[0]
"vmul.f32 s3,s17,s8 \n\t" // s3=acsDelayLine[0].stQ * *pctCoeff[0]
"vadd.f32 s0,s0,s2 \n\t" // s0+=s2
"vadd.f32 s1,s1,s3 \n\t" // s0+=s2

"subs r6,#1 \n\t"
"bne loopRAI2 \n\t"
"\nloopexitRAI2: \n\t"

"vstm %[OUT],{s0-s1} \n\t" // Write out the complex accumulator

: [IN]"+r" (pcsIn), [COEFF]"+r" (pctCoeff)
: [INCOUNT]"r" (nInCount), [OUT]"r" (pcsOut)
: "r5","r6",
  "s0","s1",
  "s8","s9","s10","s11","s12","s13","s14","s15",
  "s16","s17","s18","s19","s20","s21","s22","s23",
  "s24","s25","s26","s27","s28","s29","s30","s31"
);

*ppctCoeff=pctCoeff; // Write back the pointer
}

// This is the polyphase down sampler
__RAMFUNC(RAM2)
static int DownSample(DOWNSAMPLESTRUCT *pdss,COMPLEXSTRUCT *pcsIn,int nInCount,COMPLEXSTRUCT *pcsOut,int nOutCount)
{
COMPLEXSTRUCT *pcsX=pcsIn+pdss->nXOffset;
COMPLEXSTRUCT *pcsY=pcsOut;
COMPLEXSTRUCT *pcsEnd=pcsIn+nInCount;

while (pcsX<pcsEnd)
{
COMPLEXSTRUCT csAcc={(SAMPLETYPE)0,(SAMPLETYPE)0};
COEFFTYPE *pctCoeff=pdss->pactCoeffsTransposed+pdss->nCommutator*pdss->nCoeffsPerPhase;
register COMPLEXSTRUCT *pcsX2=pcsX-pdss->nCoeffsPerPhase+1;
int nOffset=pcsIn-pcsX2;
int nAdvanceAmount;
int nCount;

if (nOffset>0)
{
// Need to draw from the delay line
COMPLEXSTRUCT *pcsDelayLine=pdss->pcsDelayLineEnd-nOffset;

nCount=pdss->pcsDelayLineEnd-pcsDelayLine;

DownSampleInner(pcsDelayLine,&csAcc,&pctCoeff,nCount);

pcsX2+=nOffset;
}
nCount=pcsX-pcsX2+1;

DownSampleInner(pcsX2,&csAcc,&pctCoeff,nCount);

*pcsY++=csAcc;
pdss->nCommutator+=pdss->nDecFactor;
nAdvanceAmount=pdss->nCommutator/pdss->nIntFactor;
pcsX+=nAdvanceAmount;
pdss->nCommutator%=pdss->nIntFactor;

}
pdss->nXOffset=pcsX-pcsEnd;

// Manage DelayLine
{
int nRetain=(pdss->nCoeffsPerPhase-1)-nInCount;
if (nRetain>0)
{
memmove(pdss->pacsDelayLine,pcsEnd-nRetain,sizeof(COMPLEXSTRUCT)*nRetain);
memmove(pdss->pcsDelayLineEnd-nInCount,pcsIn,sizeof(COMPLEXSTRUCT)*(pcsEnd-pcsIn));
}
else
{
memmove(pdss->pacsDelayLine,pcsEnd-(pdss->nCoeffsPerPhase-1),sizeof(COMPLEXSTRUCT)*(pdss->nCoeffsPerPhase-1));
}
}
return pcsY-pcsOut;
}


[Kalvin]

Whoa! Impressive piece on coding  I have done some real-time multi-rate programming for the Motorola 56K (56300 series) processors in assembly 10+ years ago. It was quite a feat to keep the pipeline busy without too many stalls. There were somewhat less registers available, but I managed to place the data structures in the memory so that accessing and processing the data didn't require too much effort to move the data back and forth. Actually I bought two of those same boards some time ago as I happened to see these videos: and I haven't had time to do anything yet, though. I guess I did see your video too, and got impressed about the capabilities of that small microcontroller and the 80Ms/s 12-bit ADC.

[Howardlong]

The FM implementation has always been especially interesting to me. From a bit of searching and Google translating, it is an undersample followed by a downconversion using the same methods. The beauty is that the downsampling isn't as bad as it might first seem because of the undersampling and because FM channels are about 20 times wider than AM channels, so the filtering is of around the same order. For AM, we are looking at a ~10kHz channel at about 1MHz. For FM, it's a 200kHz channel at 100MHz, but as it's undersampled it's more like 200kHz in 40MHz, so it's a similar ballpark, but I couldn't find his decimation rate, the main protagonist in CPU terms. What's interesting is that the demodulation in general is generally rather petty in CPU terms compared to the downsampling and downconversion. I note from the translations that the author was running at about 97% CPU, in the same ballpark as my implementation.

For me, the implementation was an academic exercise. If you wanted to do narrow band HF, the decimation rate is just too high: at 7MHz you're looking for a 3kHz SSB, so a 2000:1 frequency ratio compared to the 100:1 or so for AM or undersampled FM. You could undersample the HF signal, but then you'd need some pretty decent filtering in the analogue domain to get the passband narrow enough.

[kanuk]

Hi  Look here:    https://youtu.be/j0qAtJdv24Y

[AF6LJ]

That's Very nice.

[piranha32]

Anyone here ever tried something like this?

This is a project in the making, that has been going for a while now (mostly conceptual/planning/reality checks up till now).  This is possible with current technology, but bloody expensive to pull off.....that is if you are "allowed" to buy the components (ever tried to buy radiation hardened FPGAs before?).

My initial requirements were:
- HF right up to UHF (0 - 500MHz) - all HAM modulations (including squeezing Codec2 into there)
- No decimation/mixing in hardware at all
- DSP for everything between the ADC and DAC (16-bit)
- Initial implementation HF only, but solution had to be able to go to a 500MHz modulated signal.
- and lastly, a simple digital LCD screen/touch/knobs/speaker solution to fill in the rest of the radio (preferably classy - technology without aesthetics is just not on).

The whole idea behind this is to filter and amplify your RF signal, and then directly sample the RF signal via the ADC, and everything leaving the DSP would exit through a DAC. All further processing (IF mixing, filtering, modulation, demodulation) is done digitally. Although it might look like a pointless exercise, it can be done....and I think one reason might be to separate the RF standard(s) from the hardware. If anything changes, you just update your firmware. Another reason would be to start implementing the open source Codec2 into hardware (I'm a big fan)

If you lower a bit your expectations, it won't be difficult to find. FDM-DUO from Italian company Elad would be one example. Receiver is implemented on a DAC feeding an FPGA, which does filtering and downconversion. Transmitter is implemented in a bit more traditional way, by upconverting digitally modulated baseband signal. Supports all major modulations (no Codec2 unfortunately, but not all is lost. Elad releases firmware updates quite regularly, so maybe one of the future ones will support it). The ADC is clocked at 122.88MHz, so the upper frequency is a bit lower than your initial requirement, but coverage from 100kHz up to 54MHz is still quite impressive. By adding a few external components (filter, amplifier) and exploiting higher order Nyquist zone, you can work in 2m band as well. All of this in a knobbed box, which can be used as a standalone QRP trx.
Aside from that they also have direct sampling radio receivers.

The Big Names of the ham radio industry are just waking up. Icom is going to release IC-7300 with direct sampling receiver, however it is still spottable (on exhibit stands) promiseware.