Teensy Convolution SDR (Software Defined Radio)

A couple of more questions:
1) Whats the power draw on the main power rail (QSD + Teensy boards combined)
2) Is it possible to add a waterfall display on the LCD? Are there any spare resources in the CPU?
3) Is it possible to use the ADCs on the Teensy CPU for sampling the I&Q (instead of the audio shield chip) and likewise use the DAC of the CPU to output the mono audio? Are there any spare resources / cycles on the CPU to do this?

TIA.
 
A couple of more questions:
1) Whats the power draw on the main power rail (QSD + Teensy boards combined)
2) Is it possible to add a waterfall display on the LCD? Are there any spare resources in the CPU?
3) Is it possible to use the ADCs on the Teensy CPU for sampling the I&Q (instead of the audio shield chip) and likewise use the DAC of the CPU to output the mono audio? Are there any spare resources / cycles on the CPU to do this?

TIA.

Thanks for the good questions!

1) as far as I remember, it is 5V, 200mA for everything. I use a 5V USB 10000mAh power bank with some common mode filtering, some caps, an auto-resetting fuse and a diode for reverse polarity protection: this output voltage is then fed into the Teensy (which then feeds the audio board) and into the 5V input of the 3V3 regulator on the QSD board. Theoretically, the power bank could power the radio for two days nonstop.

2) yes, it should be possible. The CPU still has some spare resources, I tried to optimize the code for AGC, decimation/interpolation, arctan calculations, AM demodulation algorithms, SAM calculation and I reduced the load to:
sample rate 96k (spectrum display can show a maximum of 96k width)
AGC ON/OFF
SAM: 38%/35%
SAM-Stereo: 45%/42%
SSB: 34%/30%
AM: 34%/30%

sample rate 192k
SAM: 70%/70%
SAM Stereo: nope, too heavy at this ultrahigh codec overclocking sample rate
SSB:62%/60%
AM:62%/60%

All with 180MHz Teensy 3.6, tried overclocking at 192, 216, 240MHz, but you can forget that for audio processing in the SDR, does not work properly (at these high sample rates ! at 44.1k it could be fine, but I did not test).

So, at 96k, there is plenty of CPU power for the waterfall!
You just have to implement it! ;-) And there is not much memory left, the Teensy uses 80% of the memory resources due to the large audio and FFT buffers.

3) that would be great, so we would not need the audio board anymore! But that is beyond my programming skills.
And: you only get 10-bit resolution, as far as I understand: could be sufficient, or could not . . .
BTW: I think that also stereo output is possible with the DAC on the Teensy 3.6 (which would be a prerequisite in order to use it for the Teensy Convolution SDR).
But again: you would have to implement this by yourself.

Have fun,

Frank
 
Last edited:
Thanks for the prompt reply.

Can you provide a screenshot of the Audio sketch used for the Convolution SDR? That shall help visualize the signal processing blocks, their wire-up and the signal flow.

This is similar to and as posted in the Teensy SDR document (in pdf) that shows the "two" different Audio sketeches showing the processing blocks and the signal routing thru them.

This requested sketch shall help better to understand the concept used.

Regards
 
Thanks for the prompt reply. Can you provide a screenshot of the Audio sketch used for the Convolution SDR? That shall help visualize the signal processing blocks, their wire-up and the signal flow. This requested sketch shall help better to understand the concept used.

Please have a look at the source code. You will notice that there are actually very few objects from the audio lib that are used. The reason is that the audio lib uses integer math, but convolution is easier in floating point math. Sorry, there exists no "screenshot of the audio sketch".

Maybe there is a misunderstanding: the Teensy Convolution SDR is not a beginners project. If you haven´t got experience with the Teensy and the audio lib, it will be very hard to get this thing going. My impression is your understanding of the SDR presented here could gain from starting with some smaller project, that uses the very nice Teensy audio library with the graphical audio sketches. Have a look at and work through the awesome Teensy Audio lib tutorial! After learning with that, you could later proceed with the information I already gave in the previous posts and in the wiki. That should be enough to have fun for the next weeks/months.

Well, at least it took me several months to understand the concept of how convolution is used in SDRs and how to implement it ;-).

Have fun! Frank
 
Please have a look at the source code. You will notice that there are actually very few objects from the audio lib that are used. The reason is that the audio lib uses integer math, but convolution is easier in floating point math. Sorry, there exists no "screenshot of the audio sketch".

Thanks for clarifying that.

Yes I do understand the complexity of the demod / signal processing chain.

Whats the size & resoltuion of the LCD (SPI i/f) used?
Any plans to add a touch interface?

Currently the SW has options for using Si5351 with a 25 /27MHz xtal. Are their any other options to be selected before compiling?

Regards
 
Teensy Convolution SDR has some more new features:

* when you are bored by the stations on the shortwave/medium wave bands, it now also plays MP3 and M4A files from the SD card in best HiFi stereo quality (with the excellent lib by Frank Bösing: thank you for that!)

* automatic IQ amplitude and phase imbalance correction in the time domain: this corrects imbalances that are caused by the quadrature sampling detector hardware and results in at least 55dBc mirror rejection: I implemented the algorithm by Moseley, N.A. and Slump, C.H. (2006) A low-complexity feed-forward I/Q imbalance compensation algorithm. In: 17th Annual Workshop on Circuits, 23-24 Nov 2006, Veldhoven, The Netherlands. pp. 158-164. HERE

* now supports 100ksps sample rate (only with F_CPU 180MHz) which could potentially eliminate spurs present with other sample rates

* dynamic frequency indicator figures and graticules on spectrum display x-axis

* sophisticated automatic gain control (AGC) adapted from the wdsp lib by Warren Pratt

TODO: still lacking a nice menu system . . .

Have fun with the Teensy!

Frank
 
Hi Frank,
This is a real smorgasbord of features! I appreciate your and other Teensy SDR contributors to help lift the veil on some of the mysteries of DSP. I am working with Teensy 3.5 because of its 5v IO tolerance. Regretfully it is just a little too short on RAM to compile the Convolution code. This probably due to the buffer pool needed. I am just wondering if you have any ideas where I might find optimization opportunities such as in-place fft/filtering etc. I plan to limit audio sample rate to 44.1k - does that also provide optimization possibility? Any thoughts?
Thanks in the meantime for sharing this wonderful code!
Jan
 
Hi Jan,

yes, you are right, the Teensy Convolution SDR needs a lot of memory: the I&Q buffers take 32 x 128 samples in float32_t (= 16kbytes), the FFT- and iFFT-buffers have 2048 float32_t samples each (= 16kbytes), memory for the queue buffers is at 120 (= 31kbytes) and there is a lot of other stuff for the decimation/interpolation, which need coefficient variables, state variables etc. So the memory needed is at 220kbytes at the moment . . . However, I have already tried to reduce that by decimation/interpolation: before I used a 4096 point FFT which required much larger buffers and more memory for queuing. I also re-use buffers during the realtime processing (the iFFT_buffer and the FFT_buffer is used temporarily for the two interpolation stages products). If you find some other ways to save memory, I would be very happy! Memory usage for the queues is at 110 on average.

Yes, you could use 44.1k or 48k sample rate (you can already use them now, but without memory savings): but you would have to change the whole audio chain, so that the decimation/interpolation uses lower decimation rates. Then you would not have to queue so many samples before you can perform your FFT. You could also use a 512 point or 256 point FFT which also helps a lot in saving memory. But all that is not so easily done in the code and at the moment the code does not allow for that automatically. But it could be done ! Disadvantage would be that the filtering would not be so good as the filtering at the moment. --> 8x decimation & 1024 point FFT compared to 256 point FFT and 2x decimation means the filter steepness is lower with a factor of 16.

In my view, it would be best to buy and use a Teensy 3.6, it´s really awesome how fast it is on floats . . . Do you really need the 5V tolerance? All the components for the hardware QSD are available as 3.3V parts!? [op-amps, 7474 flip-flop, LO Si5351, 3253 muxer etc.]

Have fun with the Teensy Convolution SDR!
Frank

BTW: I will put the new version into github tonight: now with many more menu points in order to adjust many variables: AGC, bass gain, treble gain, audio volume, analog gain, parameters for synchronous AM demodulation, sample rate change, spectrum zoom change, MP3-Player mode, IQ calibration, lowpass filter for spectrum display, save and load settings in/from EEPROM and many more.
 
Hi Frank, thx for the quick reply.
I see the challenge cramming this into a t3.5
I am not interfacing to QSD or Si5351. Instead I am upgrading a PicaStar design, with a straight 15kHz IF out, and a 8kHz modulation signal. (My VFO is an AD9910 driving H-mode mixer and a lot of band pass filters).
The end result will be a one-off custom design but it gives me plenty of good opportunity to Learn more about DSP. As it stands, my first design step is an additional audio component at the beginning of the loop() to convert my IF into QSD and Cohen to mix it down to base band. As a first attempt I may go back to the time domain approach of the original teensy sdr which I can fit into the t3.5, but I will keep tracking the continual goodies you keep adding (such as AGC)
Jan
 
Hi Jan,

yes, thats exactly how the Teensy Convolution SDR is meant and how it evolved: as an experience to learn DSP, not to deliver a ready-to-go-product ;-).

PIC-a-STAR: wow, I was also thinking about building one of those, but I think the approach is a bit outdated now, but it´s very nice, if you already have one and put the Teensy on the other end, sure it will bring a very nice result, I am sure!

If the IF is 15kHz, you might think about using 60kHz sample rate (you would have to search the dividers for Frank Bs sample rate code by yourself), so you can frequency translate the whole band to baseband without using multipliers in software.

What do you mean by using "Cohen to mix it down to baseband" ?
 
if you think about using a time domain approach, also consider using the Weaver approach vs. the phasing approach. Derek R has experience in that and is working on that at the moment --> HERE
 
Haha:) that's autocorrect for you.'Cohen to mix' should have been 'Then to mix'.
Thanks for the 60kHz recommendation and the link to the Weaver approach.
The choice of front ends is a bit out of scope for this forum but I'd love to see some hard measurements of Tayloe vs traditional Superhet with roofing filter for close in work to strong adjacent signals. I have tried to Google it but could not find a conclusive summary. The Piastar front end is still quite contemporary for use in crowded conditions and strong adjacent signals. The use of a separate DSP module was the only option at the time, however, it is awkward given today's low cost arm solutions. So my quest right now is to integrate the front end with a modern country/DSP and give it a clean graphical UI. Solar, I have built the new front panel and reconfiguring the hardware - a bit time consuming but progress none the less:)
 
Jan,
sounds good! I am very curious to hear about your results of giving the PIC-a-STAR a new MCU. Consequently it would have to be renamed to TEENSY-a-STAR ;-).

ADDITIONS to Teensy Convolution SDR:

* demodulation of wide FM broadcast signals (at the moment only MONO is supported): possible at 192ksps sample rate in order to pass through the WFM signal, which has 180kHz bandwidth for MONO and 246kHz for STEREO. The audio quality is superb at 192ksps and at 96ksps sample rate it is still acceptable (but no longer HiFi due to narrow-bandwidth-related distortion).

The reception of VHF signals with the same hardware is possible by undersampling reception with the QSD at the 5th harmonic (receive 95.4MHz at 95.4MHz / 5 = 19.08MHz with LO running at 4 x 19.08MHz = 76.32MHz). Undersampling reception at the 5th harmonic involves an attenuation of the signals by 14dB, so for better sensitivity a preamp is recommended for undersampling reception in the range of 88 - 150MHz. But even without a preamp the reception is quite good if you are near enough to strong FM broadcast transmitters (six FM transmitters with 100kW each in 5km distance here, so I can receive them in excellent quality with only 20cm wire as an antenna . . . ). Is STEREO reception possible? Will try that, but not very probable because of the large bandwidth needed and the excessive DSP requirements ;-)
 
Improvements in the Teensy Convolution SDR:


  • automatic test for the "twinpeak syndrome" - a fault in the mirror rejection that occurs sometimes at startup. This is now reliably detected by the automatic IQ phase correction algorithm and the codec subsequently restarted to cure the problem (Thanks, bmillier, for your help!)
  • AGC now has an optical indicator for the AGC threshold and many more AGC parameters can be adjusted
  • Codec gain has now its own automatic AGC algorithm
  • Spectrum display now also has an "AGC" that prevents an empty screen for small signals
  • now spectrum display is also working in wide FM reception (well, kind of . . . )

Have fun with the Teensy Convolution SDR!

73 de Frank DD4WH
 
Teensy Convolution SDR goes STEREO!

wide FM reception (which is possible in 3x undersampling mode) now has the ability to decode stereo FM transmissions. Took me some time to find a solution without the usual PLLs and NCOs which are quite easy to implement, but take many more CPU cycles than the Teensy 3.6 can provide (because it has to be done in 192ksps because of the enormous bandwidth of the decoded FM signal).

Stereo wideband FM decoding works as follows in the Teensy Convolution SDR (working prototype code on github: https://github.com/DD4WH/Teensy-ConvolutionSDR):
[see here for a description of an FM stereo signal: https://en.wikipedia.org/wiki/FM_broadcasting]

* FM demodulation (with complex multiply & atan2)
* baseband 0-15kHz is left plus right channel (L+R) = MONO
* high Q band pass filtering of the pilot tone at 19kHz
* rectification of the 19kHz pilot tone (if(signal < 0) signal = -signal;)
* elimination of DC by a one pole high pass filter
* high Q bandpass filter, so that the rectified 19k tone becomes a 38kHz tone (with the same phase as the pilot tone!)
* multiply the demodulated audio with the double frequency pilot tone at 38kHz --> translate the 38k L-R signal to baseband
* this multiplication produces the left MINUS right channel (which is contained in the demodulated FM audio as a DSB signal at 38kHz from baseband)
* take L+R - (L-R) = 2* R --> right channel audio
* take L+R + (L-R) = 2* L --> left channel audio
* put the audio of each channel through a one pole IIR filter for de-emphasis with tau = 50µsec (should be 75µsec in North America)
* DONE!

Even the Teensy 3.6 has no more processing headroom after that (I would have wished to add a 15kHz low pass filter, but no way ;-)), however I am very happy that it is possible to decode Stereo FM broadcast signals with the Teensy 3.6! You can manually and smoothly control the amount of left and right channel separation ("stereo factor") in the menu. Zero means MONO and 500-700 is recommended for full stereo resolution.
EDIT: it is not the processing power that limits this! Reception has now been improved and Stereo resolution is now also much better [2017_05_03]

Thanks Paul for providing such a nice microcontroller and audio library!

Have fun with the Teensy Convolution SDR,

Frank
 
Last edited:
ok you got me - i'll order the elektor sdr. (does it work with it??)

It should, this model is mentioned in the readme on github. If you don't mind a bit of SMD soldering you can also order one from Joris (you can find his email on this project page) It costs about the same as the Elektor board and there's the option to tune the bandwidth with a few capacitors. These are really neat projects, I'm hoping to build one myself pretty shortly!
 
Last edited:
help with error in line 2737 in Teensy-ConvolutionSDR.ino

help with error in line 2737 in Teensy-ConvolutionSDR.ino
error code is in line 2737 :'sincosf' was not declared in this scope

what am I doing wrong ?

i install windows 10 prof 64bits

Arduino ide 1.8.2
Teensyduinoinstall from:https://www.pjrc.com/teensy/td_download.html
etherkit/Si5351Arduino from:https://github.com/etherkit/Si5351Arduino
PaulStoffregen/SD from:https://github.com/PaulStoffregen/SD
Arduino-Teensy-Codec-lib from:https://github.com/FrankBoesing/Arduino-Teensy-Codec-lib

https://github.com/ARM-software/CMSIS/releases the zip file CMSIS 4.5.0
In according to the instruction #122
the files arm_common_tables.h ; arm_const_structs.h ; arm_math.h (geedit) to
/--/Arduino/hardware/teensy/avr/cores/teensy3

libarm_cortexM4l_math.a ; libarm_cortexM4lf_math.a to
/--/Arduino/hardware/tools/arm/arm-none-eabi/lib/

then a set board to teensy 3.6
by Verify i get error in line 2737
'sincosf' was not declared in this scope

when i the line 2737 insert with //
all is ok

than i scan my dirs op File content sincosf
With the program UltraFinder (testversion)
http://www.ultraedit.com/

c:\Program Files (86)\Arduino
c:\Users\xhenk01\Documents\libraries
c:\Teensy_Convolution_SDR (test)

there is no routine sincosf

73,PA0HAH Henk Hoekstra
 
help with error in line 2737 in Teensy-ConvolutionSDR.ino
You have to paste this code just after the #defines at the beginning :

extern "C"
{
void sincosf(float err, float *s, float *c);

}

That's all ! Regards, Silvano
 
Hi Frank excuse me but i am stopped with your code convolutional sdr with the 3.6 fft/ifft becouse i can't use the encoder
on pins 16, 17 ! Why ? I use this pins with the Teensy SDR 3.2 without problems;
i can't tune the si5351 , too... ; your code works :))) display, noise, buttons, everithing but no tune, no 16,17 working pins ?!?
I have to use pins 5,6 but i think there is another problem i can't see...
Can you help me ? Thans in advance from Silvano
 
Excuse me Frank, I use the Elektor SDR, it works perfectly with teensy 3.2, no
tuning nor reception with teensy 3.6 ...
No tuning with Convolution SDR, too.
Can you help me?
Regards, Silvano
 
Thank you for your solution

Hello Silvano,
Thank you for your solution
now it is working fine !
best wishes, Henk


help with error in line 2737 in Teensy-ConvolutionSDR.ino
You have to paste this code just after the #defines at the beginning :

extern "C"
{
void sincosf(float err, float *s, float *c);

}

That's all ! Regards, Silvano
 
Back
Top