please help
teensy 4 compil ok
stack SGTL5000
no audio in / out ??
please help
Did you enable the SGTL5000 in the original code?
If not, you have to make slight modifications to the code as suggested in post #314.
Teensy Convolution SDR (Software Defined Radio)
- Thread starter DD4WH
- Start date
Did you enable the SGTL5000 in the original code?
If not, you have to make slight modifications to the code as suggested in post #314.
Well ..I'm coming over from the arduino to the teensy side ..I'm got all the parts to move forward with the project...I've got one question regarding the xls file for the sdr build on github ..are there any issues with the pinout ? ..I reviewed it and it makes sense , just curious if there are any gotchas...as a side note..I'm in amature radio operator and a communications engineer ..retired .. so not new to projects or programming ..
Thanks in advance
Thanks in advance
I'd add a 100Ohm R to the clock and MOSI to the display. Connection to touch or MISO is not needed.
Place the frontend as far as possible from the Teensy and display. (And use a Teensy 4).
Edit: Dont use the Audio shield - use PCM1808 / PCM5102 instead.
You'll get a great radio.
Thanks for the quick reply Frank ..I'm running a mini circuits psc2-1 rf combiner splitter at the front end paired up to a set of Sbl-1 balanced mixers ...they'll be in their own shielded box ...I've not gone over the code to a great degree yet .. but are you clocking at 4x with the si5351 then dividing down to get quadrature ? ..I know the si5351 can generate quadrature down to about 3.2 MHz directly ..
DD4WH
Well-known member
Hi Keith,
not sure how your frontend looks like, but a standard quadrature sampling detector does not need standard SBL-1 mixers and a splitter with the associated high losses. Do you use a "Tayloe" type of frontend to produce the quadrature input signal at baseband / low IF that feeds the ADC? The "Tayloe" frontend has about 1dB loss (because it is not a mixer, but a sample-and-hold) and very high input IP3. Should be much better than a splitter and two diode mixers. You can find schematics and explanations on that in the link & resource section (see Youngblood 2002) in the WIKI of the Teensy Convolution SDR github page.
Yes, the UHSDR and the QCX are able to use the Si5351 with two outputs 90 degrees out of phase. However, as you said, it is not possible to do this below about 3.x MHz. Thats why it is not used by the Teensy Convolution SDR at the moment. If frequencies below 3.xMHz do not interest you, it is a good idea to do it like this.
The sbl-1 solution is what I have handy ... I do have an sdr kit on route from qrp labs ..which is Tayloe based ...don't know when it will get here though ..thought I'd throw the sbl front end into it to test .. and yes at least 5 to 6 DB loss ..I had to drop a 10Db pre-amp on it for "make up gain"..which in turn compromised the ip3 point .....
Greetings everyone, I've been trolling here for sometime but this is my first post, yes, with a question. First, thank you for the fantastic project, truly amazing contribution from everyone. I got very interested and read through the posts (I think) in full. I also put together the receiver based on Frank's (DD4WD) wiring docs and source. My hardware is a T4 with Elektor front-end. I used Arduino IDE 1.8.12 with Teensduino 1.51 to compile the source and after adjusting the the definitions for the correct hardware and Si5351 port / clock compiled just fine.
This I did under MacOS 10.13. One thing I did not install is the ARM CMSIS DSP library, cause I couldn't figure out how to for MacOS. Is this an absolute imperative when using T4 ?
I figure this maybe my issue cause the receiver seem to function - I have signals on the spectrum screen but when I tune all I get is noise and gibberish on all bands. I figured decoding may not be working due to the missing libraries ? Mind you, the compiler never complained.
Could you please confirm if this is something I need to install and that maybe my issue here.
Thanks in advance.
This I did under MacOS 10.13. One thing I did not install is the ARM CMSIS DSP library, cause I couldn't figure out how to for MacOS. Is this an absolute imperative when using T4 ?
I figure this maybe my issue cause the receiver seem to function - I have signals on the spectrum screen but when I tune all I get is noise and gibberish on all bands. I figured decoding may not be working due to the missing libraries ? Mind you, the compiler never complained.
Could you please confirm if this is something I need to install and that maybe my issue here.
Thanks in advance.
DD4WH
Well-known member
Hi Les, nice to hear that you had success in building the SDR!
* with T4.0/T4.1, you do not need to install a newer version of CMSIS. This is only necessary with Teensy 3.6
* I would strongly recommend to use the newest Teensyduino version: https://forum.pjrc.com/threads/60911-Teensyduino-1-52-Released
* also, be sure to use the latest sketch version from my github
* Not sure, but your problems with having no signals could be due to the old Teensyduino version, but also check the following:
* use the Si5351 library by Etherkit
* check the right setting for your Si5351 crystal in the #define --> 25 or 27Mhz
* check the right setting for Si5351 CLK in the #define --> could be 1, 2, or 3 depending on your frontend
EDIT: crosspost with FrankB, who obviously had the same idea ;-)
* with T4.0/T4.1, you do not need to install a newer version of CMSIS. This is only necessary with Teensy 3.6
* I would strongly recommend to use the newest Teensyduino version: https://forum.pjrc.com/threads/60911-Teensyduino-1-52-Released
* also, be sure to use the latest sketch version from my github
* Not sure, but your problems with having no signals could be due to the old Teensyduino version, but also check the following:
* use the Si5351 library by Etherkit
* check the right setting for your Si5351 crystal in the #define --> 25 or 27Mhz
* check the right setting for Si5351 CLK in the #define --> could be 1, 2, or 3 depending on your frontend
EDIT: crosspost with FrankB, who obviously had the same idea ;-)
DD4WH
Well-known member
Hmm . . .
1.) the main filter is a complex convolution filter which calculates the coeffs with a function in the sketch. It does NOT use the CMSIS FIR filter function
2.) the CMSIS FIR filter is used in the following places:
a.) decimation and interpolation: but here I think it does not make any difference, because linear phase FIR filter coeffs for real signals are symmetric (but I could be wrong)
b.) it should make a difference for FIR Hilbert filters, but do we use them at some place with CMSIS functions? In SAM demodulation, we use them, but that uses some weird halfband filters designed by Warren Pratt without CMSIS functions. In WFM demodulation, we use Hilbert filters WITH CMSIS. We can have a look at that, I cannot decide at this point, whether it is important or not. But worthwhile having a look at that!
Edit: had a look at the code: it seems the FIR Hilbert filters for the wideband FM receiver that are responsible for creating I & Q from the MPX signal in order to lock to the 19kHz pilot tone are the only ones that could potentially suffer from this. All other filters are either not CMSIS filters or are simple lowpass filters with symmetrical coeffs.
1.) the main filter is a complex convolution filter which calculates the coeffs with a function in the sketch. It does NOT use the CMSIS FIR filter function
2.) the CMSIS FIR filter is used in the following places:
a.) decimation and interpolation: but here I think it does not make any difference, because linear phase FIR filter coeffs for real signals are symmetric (but I could be wrong)
b.) it should make a difference for FIR Hilbert filters, but do we use them at some place with CMSIS functions? In SAM demodulation, we use them, but that uses some weird halfband filters designed by Warren Pratt without CMSIS functions. In WFM demodulation, we use Hilbert filters WITH CMSIS. We can have a look at that, I cannot decide at this point, whether it is important or not. But worthwhile having a look at that!
Edit: had a look at the code: it seems the FIR Hilbert filters for the wideband FM receiver that are responsible for creating I & Q from the MPX signal in order to lock to the 19kHz pilot tone are the only ones that could potentially suffer from this. All other filters are either not CMSIS filters or are simple lowpass filters with symmetrical coeffs.
Last edited:
I've added a simple reverse-array function to my WFM implementation.
Not sure if there is a audible difference... might be slightly better...not sure..
edit: and I have switched the stereo-decoding to time division multiplexing. this makes a difference, audible, as the "amplitude" of the sin(phase) gets eliminated and is just 1 or 0 - But the phase-correction-factor (const) needs to be more exact.
Not sure if there is a audible difference... might be slightly better...not sure..
edit: and I have switched the stereo-decoding to time division multiplexing. this makes a difference, audible, as the "amplitude" of the sin(phase) gets eliminated and is just 1 or 0 - But the phase-correction-factor (const) needs to be more exact.
Last edited:
"Zeitmultiplexverfahren" - das wird in den ganzen 3mm Chips auch eingesetzt.
Means to switch with 38kHz between L and R. A German link: https://elektroniktutor.de/geraetetechnik/stereo.html#multiplex
Code:
[B]uint8_t[/B] m_PilotPhase[WFM_SIZE];
....
m_PilotPhase[i] = [B]signbit[/B]( arm_sin_f32( (m_PilotNcoPhase - [B]0.25[/B]) * 2 ) ); //<- the 0.25 is const but needs to be adjusted to the filter-delays once
....
right[i] = mpx[i] * 2 * !m_PilotPhase[i]; //<- note, mpx[i] 2x only now, no adding/subtracting like in your version
left[i] = mpx[i] * 2 * m_PilotPhase[i];
...The phase from the 19kHz PLL need to be more exact now, with this change. I'm still not sure if it is OK to use a IIR as input for the 19kHz PLL... maybe yes because of the low-pass in the pll--maybe not...
Audio 15kHZ filtering after this is essential. Perhpas better to do it before deemphasis(?)
Apart from that, using this addition is a little bit better for the generating the mpx
Code:
[...]
float I = float_buffer_L[i];
float Q = float_buffer_R[i];
[B] float a = sqrtf( I * I + Q * Q );[/B]
I /= a;
Q /= a;
mpx[i] = atan2f( I_old * Q - I * Q_old, I_old * I + Q * Q_old ) * mult..;
[....]..but I plan to remove that completeley and use a PLL instead. It is essential to have the exact fm-frequency if you want it as noiseless as possible.
Last edited:
I am new to the forum. Thank you DD4WH for the excellent work on the SDR. It is really interesting. So interesting that I bought all the parts and put one together.
I am using a Teensy 4 with the PCM1808 ADC and PCM5102A DAC and followed the pinout in the provided Excel file plus I added 100 Ohm resistors to the clock and MISO lines on my ILI9341 TFT display per Frank B's post. I have read all 14 pages of this thread. I am pretty sure I have built the DD4WH_T4 hardware correctly as far as I can tell. I have the HARDWARE_DD4WH_T4 define uncommented.
I am probably doing something dumb here, but my display shows nothing. If I load up the Adafruit graphicstest.ino (modified so the pins are correct per the convolutionSDR) the display works fine. When I load the latest (May 8 2020) Teensy_Convolution_SDR code, I get a white screen. The serial monitor shows "Found EEPROM version mr1... a bunch of filter coefficients... a couple of decimation stage number of taps, the FlexRAM-Banks and some info about the memory." The Teensy seems to be running okay.
If I enable the debug, I get the same info, then the twinpeaks counter counts up to 800 and then I get "microsec for 16 stereo blocks" and "n_clear 0" slowly repeats forever.
Am I getting stuck before the screen is written? I have been digging through the code and figuring it out bit by bit, but there is a lot of code!
I am an electronics engineer so the hardware doesn't scare me. My software skills are not so great, but I can follow most of the code. I don't have any trouble with the filters and FFT stuff.
Anyhow, if anyone has any ideas to share I appreciate it.
Thanks!
I am using a Teensy 4 with the PCM1808 ADC and PCM5102A DAC and followed the pinout in the provided Excel file plus I added 100 Ohm resistors to the clock and MISO lines on my ILI9341 TFT display per Frank B's post. I have read all 14 pages of this thread. I am pretty sure I have built the DD4WH_T4 hardware correctly as far as I can tell. I have the HARDWARE_DD4WH_T4 define uncommented.
I am probably doing something dumb here, but my display shows nothing. If I load up the Adafruit graphicstest.ino (modified so the pins are correct per the convolutionSDR) the display works fine. When I load the latest (May 8 2020) Teensy_Convolution_SDR code, I get a white screen. The serial monitor shows "Found EEPROM version mr1... a bunch of filter coefficients... a couple of decimation stage number of taps, the FlexRAM-Banks and some info about the memory." The Teensy seems to be running okay.
If I enable the debug, I get the same info, then the twinpeaks counter counts up to 800 and then I get "microsec for 16 stereo blocks" and "n_clear 0" slowly repeats forever.
Am I getting stuck before the screen is written? I have been digging through the code and figuring it out bit by bit, but there is a lot of code!
I am an electronics engineer so the hardware doesn't scare me. My software skills are not so great, but I can follow most of the code. I don't have any trouble with the filters and FFT stuff.
Anyhow, if anyone has any ideas to share I appreciate it.
Thanks!
WH7U welcome to the forum,
let me see if any of my suggestions help. I'd say please check your the graphics library you use and the wiring. When you say you load the latest version, I take that you get a successful compile, which gets loaded into the T4. If you correctly uncomment #define HARDWARE_DD4WH_T4 in line 198, the compiler should correctly pull the ILI9341_t3n library. Whilst that library was based on the Adafruit library, is has since been heavily modified and comes with its own graphicstest.ino You can access that version from File/Examples/ILI9341_t3n/graphicstest. Make sure you can get that verison running. Also TFT-Reset is connected to +3.3V. If you compile, load and get that verision running, your SDR code should come up as well.
In fact, this is how I started putting my hardware together. Had the ILI9341 screen connected to the T4, compiled and loaded ConvolutionSDR. To get the main UI running, you don't need the ADC ,DAC, or anything else connected - just the Tennsy and the screen. Thereafter, you can start connecting everything up and validating functionality.
I hope this makes sense and helps.
let me see if any of my suggestions help. I'd say please check your the graphics library you use and the wiring. When you say you load the latest version, I take that you get a successful compile, which gets loaded into the T4. If you correctly uncomment #define HARDWARE_DD4WH_T4 in line 198, the compiler should correctly pull the ILI9341_t3n library. Whilst that library was based on the Adafruit library, is has since been heavily modified and comes with its own graphicstest.ino You can access that version from File/Examples/ILI9341_t3n/graphicstest. Make sure you can get that verison running. Also TFT-Reset is connected to +3.3V. If you compile, load and get that verision running, your SDR code should come up as well.
In fact, this is how I started putting my hardware together. Had the ILI9341 screen connected to the T4, compiled and loaded ConvolutionSDR. To get the main UI running, you don't need the ADC ,DAC, or anything else connected - just the Tennsy and the screen. Thereafter, you can start connecting everything up and validating functionality.
I hope this makes sense and helps.