Direct Digital Sampled RF Transceiver

[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;
}