-
Now I am thinking how I should implement the decimating FIR into the ARM, using again some sweet optimalization techniques. But it seems I could reuse the code I have now, only modify it to use multiple pointers, initialized with offset of M samples, where M is the decimating factor.
I have just looked into the arm_fir_decimate_fast_q15.c on their implementation. Seems they calculate only two samples at once, instead of four (as I have in my implementation now). Is there any reason why only two at once instead of four? (I suspect there is not enough registers left to do the calculation of four at once efficiently).
Now I use 48kHz input sampling rate. Because the audio I am interested in (telephony) has the range of only about 300Hz to 3kHz, would it make sense I should apply decimation by 4, to produce output of 12kHz (or possibly 6x, downto 8kHz), to save computing time?
If I understand that right, the decimating FIR filter is still calculated as for the higher/input sampling rate, 48kHz in my example? That would lead to very high order of the filters, to get the desired bandwidth/selectivity in the receiver. Does it make sense to design the decimating FIR only to suppress aliasing and then use separate sharper filtering on the downsampled signal?
Look what I have found! MC1350 (Datasheet) - Seems like a reasonable part for my final design :-) -
Yes. Basically you combine a decimation FIR filter with the decimation operation (see 2.3 Implementation):
http://dspguru.com/dsp/faqs/multirate/decimation
Using a simple multirate technique, you can make things in very efficient way, too:
http://www.ws.binghamton.edu/fowler/fowler%20personal%20page/EE521_files/IV-05%20Polyphase%20FIlters_2007.pdf
I am not sure that doing a polyphase decimator is going to be worthwhile for a decimation by four, but for larger decimations it most certainly will be computationally worthwhile. From a complexity perspective I would try to avoid it, but sometimes it's essential.
Polyphase is nice if one wants to keep a constant load on the CPU ie. for each new sample something will be processed. This will require a simple state machine in the filtering routine and downstream processing routines. Yes, it may cause some headache, too. The good property of the polyphase implementation is that it will keep the CPU load typically quite constant as the CPU will compute partial results at every sample instant.
The other solution is to process the complete decimator every fourth sample. Implementation will be straightforward, but the CPU will be very busy at every fourth samples. Depending on the implementation this may be a problem or not if the CPU cannot do real-time processing task at every sample instant.
Quite often in real-time applications (like audio signal processing) one needs to do some real-time processing at each sample instant and output updated data at sample rate. If the data cannot be processed at each sample instant due to long processing delay, this may be a problem. The cure is to add more raw CPU horsepower or do something clever, like polyphasing. -
I use input and output buffers of 1K length now (about 20ms at 48ksps), so calculations are done in bursts whenever the CPU has time && buffers are not full. That way I can even pause the CPU for a few milis to do other tasks (considering it can refill the buffers quick enough in the remaining time).
I am also going to use FreeRTOS probably to make the programing of the UI simplier.
I like the asynchronous processing much more. Here is no need to avoid the input-to-output delaying of the signal. -
I have just looked into the arm_fir_decimate_fast_q15.c on their implementation. Seems they calculate only two samples at once, instead of four (as I have in my implementation now). Is there any reason why only two at once instead of four? (I suspect there is not enough registers left to do the calculation of four at once efficiently).
Now I use 48kHz input sampling rate. Because the audio I am interested in (telephony) has the range of only about 300Hz to 3kHz, would it make sense I should apply decimation by 4, to produce output of 12kHz (or possibly 6x, downto 8kHz), to save computing time?
If I understand that right, the decimating FIR filter is still calculated as for the higher/input sampling rate, 48kHz in my example? That would lead to very high order of the filters, to get the desired bandwidth/selectivity in the receiver. Does it make sense to design the decimating FIR only to suppress aliasing and then use separate sharper filtering on the downsampled signal?
Look what I have found! MC1350 (Datasheet) - Seems like a reasonable part for my final design :-)
They probably ran out of registers. If you look at the floating point version, ISTR it's four at a time.
The CMSIS DSP decimator at present is NOT polyphase but functionally it will do the job.
With higher decimation, higher tap FIR filters are going to be needed, or some other means of anti alias filtering. That is where polyphase filtering and decimation comes in.
However, unless you really are running out of CPU, I would keep it modular and simple. Having to amalgamate functionality can be great for performance but is a bitch for maintenance. That's just one of those engineering conundrums, compromise!
Edit:
Yes, decimate by 4 or 5 or so, then do your more stringent processing on that. I did almost exactly that in the narrowband telemetry decoder for the FUNcube series of satellites. -
Ok, now I can filter data using FIR (or do the Hilbert which is also FIR). For my original idea, I would like to test AM demodulation first, because it seems to be the simpliest and most straightforward.
I obviously do need a square root. :-) Until now, for an integer sq root I've been using some fast implementation found on the web. It calculates really integer square rooot, not fractional. But I think it doesn't really matter here. The implementation finds the root in about 280 cycles on Cortex M0 and I think that was with O0, not O3 even Os.Haven't tested the performance on CM4 or CM3 yet.
It could be worth a consideration to use teh FPU here. Convert the u32 to f32, find the root with the FPU (does in 14 cycles I think) and then convert it back to u16.
But there is a catch. The square root returns only positive values. So how can I get rid of the DC offset in the signal the easiest way? I haven't googled yet, so I am going to do so now.
There is the code for the fast u32 sqrt. It also returns the remainder.Code: [Select]/**
* @brief Calculates square root of aa, integer numbers. Returns also
* the remainder. So for 27 it returns 5 and remainder of 2.
* @note None
* @param aa: integer number to be rooted, input 2^32-1 (4294967295) maximum
* @param *rem: pointer to the remainder variable to be filled
* @retval integer trunc of square root of aa
*/
uint16_t sqrt32r(uint32_t aa, uint32_t *rem)
{
uint32_t b = 1 << (32-2);
uint32_t a = 0;
while (b != 0) {
if (aa >= a + b) {
aa -= a + b;
a += b << 1;
}
a >>= 1;
b >>= 2;
}
if (rem) *rem = aa;
return a;
} -
Now I use 48kHz input sampling rate. Because the audio I am interested in (telephony) has the range of only about 300Hz to 3kHz, would it make sense I should apply decimation by 4, to produce output of 12kHz (or possibly 6x, downto 8kHz), to save computing time?
If I understand that right, the decimating FIR filter is still calculated as for the higher/input sampling rate, 48kHz in my example? That would lead to very high order of the filters, to get the desired bandwidth/selectivity in the receiver. Does it make sense to design the decimating FIR only to suppress aliasing and then use separate sharper filtering on the downsampled signal?
You can think the decimation as follows:
You have a sample rate of 48kHz but your signal is only in range 300Hz - 3kHz. You could process the signals 300Hz-3kHz at 48kHz sample rate, but you are wasting cycles as the required sample rate is 6kHz (twice the highest signal component).
So, you want to decrease the sample rate. From the sampling theory you know that 6kHz sample rate is the absolute minimum for the 3kHz signal bandwidth. But in order to make your life a bit easier, the 12kHz sample rate is a good compromise as the decimation filter could be a bit relaxed etc. and you won't get aliasing that easily. As a result, you want to perform 1:4 decimation.
Now, you need to filter all the frequency components above 3kHz ie. you want to create a 3kHz low-pass filter at a sample rate of 48kHz. You want to have a FIR filter as it is suitable for decimation process, it has a linear phase response, it is always stable etc.
Here is the best part: Yes, you need to compute the 3kHz low-pass FIR at each sample instant ie. at 48kHz rate. However, as part of the decimation process you will use only every fourth output sample of the decimation filter. As the FIR filter doesn't have any recursive structures as an IIR filter has, you need to just compute the FIR at every fourth sample instant that you are interested in. You don't need to evaluate the FIR filter at those sample instants that you will discard anyway as a result of decimation.
Polyphase? Well, polyphase would distribute the processing load more evenly.
About software architecture. Divide the software into two parts: "foreground" and "background".
First part is the "foreground" process ie. the real-time signal processing part which will be handled in the interrupt service routine at sample rate of 48kHz.
The second part, "background" will be at main() function level handling the UI and other non-real-time stuff. The "background" it will be interrupted by the "foreground" process at 48kHz rate, thus the "background" process will get the remaining processing cycles which are not used by the "foreground" process. -
I understand the interrupt solution, but I haven't chosen it, not today :-) I do not say which is better or not, both can offer some advantages and disadvantages. I could possibly reimplement it as it'd be needed.
Ok, DC removal possibly solved with this, what do you think? http://www.digitalsignallabs.com/dcblock.pdf
But still a curious question: Subtracting mean value out of the signal (moving averager with delay line, Fig 3A):
What if I omit the delay line before the subtraction? (Phase will change, nonlinearly, possibly?)
What if I replace the moving average with something like this (first order lowpass, exponential step response)?Code: [Select]out = (out*N + in) / (N+1)
This is very easy to implement and ultrafast. No another circular buffering, as suggested in the pdf above.
Or how do you solve the DC offset after the sqrt demodulator in your radios? -
Or how do you solve the DC offset after the sqrt demodulator in your radios?
With an AC coupling capacitor?
More seriously, if you are already implementing a 300Hz to 3kHz BPF there should be no DC anyway. -
Ok, now I can filter data using FIR (or do the Hilbert which is also FIR). For my original idea, I would like to test AM demodulation first, because it seems to be the simpliest and most straightforward.
I obviously do need a square root. :-) Until now, for an integer sq root I've been using some fast implementation found on the web. It calculates really integer square rooot, not fractional. But I think it doesn't really matter here. The implementation finds the root in about 280 cycles on Cortex M0 and I think that was with O0, not O3 even Os.Haven't tested the performance on CM4 or CM3 yet.
It could be worth a consideration to use teh FPU here. Convert the u32 to f32, find the root with the FPU (does in 14 cycles I think) and then convert it back to u16.
But there is a catch. The square root returns only positive values. So how can I get rid of the DC offset in the signal the easiest way? I haven't googled yet, so I am going to do so now.
Why do you need a Hilbert transform if you already have the IQ from your Tayloe mixer?
Lots of ways to do square roots, as you have probably found. Again, Richard Lyons' two books on DSP, the Understanding one and the Streamlining one will help here. The same goes for DC offsets, loads of suggestions in his books for that old chestnut, but I am not sure you need it if the signal is band limited already, and you are always taking the square root of the sum of two squares... ie, the argument to the square root is always going to be posiitive. -
OK, sorry, I misunderstood, the output of the square root, well yes, I'm afraid it is an AC coupling capacitor after all. Whether you use a DAC or PWM, unless the DAC is bipolar output, the old fashioned AC coupling cap will be the solution.
-
You know... Hilbert is neccessary for SSB. I don't want to end with AM reception only. (or do I need it actually? with IQ signals?)
In this setup there is only some filtering on the IQ signals. That won't cancel the dc after the sqrt no way. See the imgae below please.
The square root returns positive numbers only corresponding to the input signal strength. The information is then superimposed on the DC. The DC should be equal to the signals idle level (without modulation) and needs to be subtracted.
It is the same as with analog detector. At idle (without modulation) you will see a DC on the output. You then just AC couple the output of the rectifier circuit. The same happening in the DSP I think. And I am just questioning, how to remove the DC component in the DSP, If I'd set my mind not to use another FIR after the sqrt (which have also a limited suppresion of the DC).
OK, then! But the cap after the DAC is a little ... eh... "solution" :-)
If I'd need to implement a recording function in the radio, I'd still need to filter it. You don't want your wav with just too much offset.:-)
-
No Hilbert is required for SSB if you have IQ already. The demodulation for SSB is _reallly_ simple compared to AM.
-
Ok then. Simple enough. Saidly I have no reliable source of SSB signal here. Unfortunately my FT-225R has broken VFO (or the related PSU?) and needs repair. By using a downmixer (SAA602 or similar) it would have been used as a reference signal source...
I have tried to build my own SW (80m band) QRPP DSB transmitter a few times, but none of them actually worked well. Always very bad carrier supression.
-
Another bible for you
http://www.arrl.org/files/file/Technology/tis/info/pdf/020708qex013.pdf
http://www.arrl.org/files/file/Technology/tis/info/pdf/020910qex010.pdf
http://www.arrl.org/files/file/Technology/tis/info/pdf/021112qex027.pdf
http://www.arrl.org/files/file/Technology/tis/info/pdf/030304qex020.pdf
This, together with Rick Lyon's Understanding book, were the two primary texts I used when learning DSP. I had plenty of other texts, these were *by far* the most useful.
The quadrature signals chapter from the Rick Lyons book is publicly reproduced here: http://dspguru.com/sites/dspguru/files/QuadSignals.pdf
For a signal source, do you have a canned oscillator, say 1MHz or so, or one you can divide down as necessary to the frequency of interest? But a couple of inches of wire on pin 3, it should be a very loud carrier. -
By the way, forgive my perhaps terse response about the Hilbert and SSB demodulation: I was trying help by giving you a bit of direction without actually giving you the answer :-)
If you are stuck, let me know. -
I am already reading/using the literature on this arrl site: http://www.arrl.org/software-defined-radio
The DSP Tutorial from Doug Smith KF6DX there is also very useful!
The other pdf you sent (from Rick Lyon) - I am sure I have seen that - but silly me haven't saved the url, probably. Thanks!
Yeah, a lot of canned XOs. By using another XO with 4*f a few kHz tweaked I could feed the Tayloe... that would work for a test! Thanks for the idea. Will test that soon.
The only problem now is my free time, this week I will be probably very busy... but I am excited to test it.
//No no not stuck yet. Your help is welcome. Now I have got I think most of the stuff I need for a quick test - except the HW. (It will take some time for parts to arrive and more time for the PCBs). I might quick-test it with a HCT4052. That must work too. And I think I have got also some better MUXes from Vishay or AD... Only need to find them.
So I hacked up some basic schematic for the SDR AFE... It should work.. I hope. Luckily, the 14.318M crystal divided by 4 fits nicely inside the 80m band.
Consider it "the first test ever", revision 0.
-
http://www.ijera.com/papers/Vol4_issue4/Version%201/BM044394397.pdf
http://www.google.sk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB8QFjAAahUKEwihmdjPxJLGAhXJ0xQKHXaYAPE&url=http%3A%2F%2Felectronics.stackexchange.com%2Fquestions%2F16571%2Fsff-sdr-how-to-implement-a-simply-program-in-the-fpga&ei=OjV_VaGUJ8mnU_awgogP&usg=AFQjCNEX9S8bamDK-F-6zIXC7KYKsIXt7A&sig2=HR37Z-dSgu-rJrt3ryucQw&bvm=bv.95515949,d.bGQ
https://www.wpi.edu/Pubs/ETD/Available/etd-042711-091356/unrestricted/solivieri.pdf
-
Hi M.,
thx 4 the links, but I can't get the relation. The topics discussed there are indeed interesting, unfortunately out of my scope. I can't do FPGAs well enough yet to try implementing such things. My skill with these devices is making a programmable counter/clock divider :-)
So the first prototype board has been made. We'll se if it'll work a bit. Soon.
-
So there's the hardware. I´ve updated the schematic above to exatly match the hardware I've built: http://z56.imgup.net/IMG_360390bd.JPG Not pretty, I quite rushed with that thing.
The 14.318M oscillator works just fine, so does the johnson counter.
To test the HW, I've connected it to a PC soundcard. Software I use is SDR Sharp (SDR#).
As a test signal source I've found my very old 3-transistor MW AM transmitter. The SDR is receiving on 14.318/4 = 3.579MHz. So I've tuned the transmitter to about 1.19MHz to receive the third harmonic, which is 3.567MHz - just 12kHz under the center frequency of the SDR.
And it does receive. You can clearly see the sharp spike, which is the transmitter. But why's there the second mirrored spike? Shouldn't be there only one? The two are mirrored against the center. frequency. I think there should be visible only the left one spike. What's possibly wrong with it?
The left one signal seems also a few dB stronger, than the right one. Swapping IQ signals does change the strength levels of the two spikes. So it is probably doing something, but why do I see the image frequency so strong?
Thank you for your suggestions. -
Nice progress, Yansi.
Does the amplitudes of the two spikes change as you change the TX frequency? If the I and Q signals suffer from phase and/or amplitude imbalance, this might show up as something like you are now seeing. Unfortunately I haven't bee playing with SDR, so I cannot be more specific here. -
There might be something onto that. The SDR# software provides a selection of "IQ correction". I've switched that on and after a while the image peak slowly dissapeared, as it was integrating the phase and gain number (written in the window caption). It ended up somewhere about 1.4 gain imbalance and 30 to 40 degree correction. Interesting, mmm...
So the HW impurities can be cleansed with some clever processing algorithms. (That I don't know, now). I think it'd be bettter to avoid problems dirrectly in the HW.
So my first thought is: I've used quite regular SMD components with I think 5% resistance tolerance and standard ceramic caps with 5 or 10%. Nothing anywhere near perfect.
The first thing which can distort phase in my circuit easily are the two caps in the feedbacks of the the opamps. I've put there quite large ones, to make the lowpass filter more filter stuff I don't want into the ADCs. So I'll try to remove them and use only decent one (a few hundred puffs at max). I will also change the feedback resistor, I will try to select two with matching resistance.
Btw, if I tune the transmitter near the center frequency of the SDR, some other spikey thing starts coming up. That is also not probably good behavior: http://p06.imgup.net/asfdasdassdde3.png
Already changed the caps and paired (they match good enough without any special selection) the resistors. It is a little better I think, but still I think too bad so one can't be satisfied. So lets hunt the error again. But where? Do you have any ideas?
-
I would think that the IQ imbalance (which all analogue quadrature mixers have) is mostly due to the choice of relatively slow parts for both the switches and counter. I was thinking about mentioning this earlier, but I didn't want to put you off getting started on the hardware!
10dB image isn't great, but as you've found SDR# does a reasonable job of correcting it.
This is due to the phase and amplitude imbalance between the I and Q channels. Typically 40dB image rejection is a reasonable figure for this, so you still need to fix it in software.
For a relatively narrow band such as yours this is achieved by a couple of constant multiplies and adds on the raw I and Q samples. Figuring out what those constants are is a little more complicated though! SDR# uses a stochastic method, it applies a few reasonably well chosen random values to one of the two constants and chooses the best one (by measuring the greatest power difference in the upper and lower FFT spectra). It then does the same with the second constant. It repeats the process iteratively, as the constants are not mutually exclusive. Nice and easy to do on an x86 where you're hardly short of power, not so much on an MCU, but still very feasible as a non-priority task. -
Now I am listening to EA3JE from Barcelona, Spain. At 3,598MHz or thereabout. .. but he's off now.
The SDR is indeed doing something, see how many stations I see in the 48kHz span. Unfortunately, the receiver has got low sensitivity, so I can barely understand what they are talking about. This capture is already with a two transistor preamp (20dB voltage gain) added on the input and of course with 3.rd order highpass filter, to get rid of that local three quarter megawatt middlewave transmitter.
There is I think still something wrong with the HW: I've added a trimpot to on of the channel to finetune the gain. But it doesn't help a tiny bit to suppress the image.
This is a revision zero hardware, better parts are already on their way. I contacted my HAM friends, I might borrow someone's already working SDR receiver so that I can focus on the software part. -
What's your antenna?
-
About 5 to 6 meters of untuned wire hanging in my room. Better than nothing. O0 (Usually enough for commercial receiver to get these strong stations without much strugle)