Teensy Convolution SDR (Software Defined Radio)

Frank DD4WH
I should have checked my statement. I keep making these bad assumptions on what I'm seeing when debugging. I'll post the code when its cleaned up a little more and I have checked for more mistakes.
 
Frank DD4WH
Having an issue with something clobbering a global variable. Isolated it a little. Seems to happen in setup when calling calc_cplx_FIR_coeffs(...)

Using your latest GitHub:
after line 598
uint8_t write_analog_gain = 0;
added
boolean gEEPROM_current = false; //mdr at line 599d

after EEPROM_LOAD(); at 1895
added
gEEPROM_current=true; //mdr

before calc_cplx_FIR_coeffs (... at 1961
added
Serial.print("line 1957 in setup before calc_cplx_FIR_coeffs (... gEEPROM_current = ");Serial.println(gEEPROM_current);

after calc_cplx_FIR_coeffs (...
added
Serial.print("line 1975 in setup after calc_cplx_FIR_coeffs (... gEEPROM_current = ");Serial.println(gEEPROM_current);

Here's the result when starting up with the EEPROM already filled:

Code: 
1957 in setup before calc_cplx_FIR_coeffs (...    gEEPROM_current = 1
1975 in setup after calc_cplx_FIR_coeffs (...    gEEPROM_current = 0
decimation stage 1: no of taps: 28
decimation stage 2: no of taps: 46
fstop2: 0.30
fpass2: 0.20

Please tell me how I'm messing up this time, I'm going nuts :)
 
bicycleguy,

thanks for your very good and precise observation!

Probably my fault, sorry!

It could be that this odd behaviour is caused by a buffer overflow (that is my fault!):

please change this in function

void calc_cplx_FIR_coeffs (float * coeffs_I, float * coeffs_Q, int numCoeffs, float32_t FLoCut, float32_t FHiCut, float SampleRate):

Code: 
//  for (i = 0; i < FFT_length; i++) // WRONG! causes overflow, because coeffs_I is of length [FFT_length / 2 + 1]
  for (i = 0; i < numCoeffs; i++) //zero pad entire coefficient buffer
  {
    coeffs_I[i] = 0.0;
    coeffs_Q[i] = 0.0;
  }

and try again ;-). Have not tried this due to time constraints, but I hope it solves the problem . . .

All the best,

Frank DD4WH
 
DD4WH said:
...
please change this in function

void calc_cplx_FIR_coeffs (float * coeffs_I, float * coeffs_Q, int numCoeffs, float32_t FLoCut, float32_t FHiCut, float SampleRate):

Code: 
//  for (i = 0; i < FFT_length; i++) // WRONG! causes overflow, because coeffs_I is of length [FFT_length / 2 + 1]
  for (i = 0; i < numCoeffs; i++) //zero pad entire coefficient buffer
  {
    coeffs_I[i] = 0.0;
    coeffs_Q[i] = 0.0;
  }

and try again ;-)
...
Frank DD4WH
Click to expand...

Wow, that fixed it. Hard to believe with that large an overrun anything worked !

I was going to do a pull request but I'll update to your new latest first.

thanks
 
Frank B said:
With SGTL5000?
Click to expand...

I was using the PJRC Audioboard with a sampling rate of 360 kHz.

IIRC
at 360 kHz, noise is terrible, but it sampled
last acceptable sampling frequency was 240 kHz
last low noise sampling frequency was 96 kHz
(its a while now, that I did these tests)

EDIT:
the tests done are discussed in https://forum.pjrc.com/threads/52798-Overclocking-SGTL5000?p=181609&viewfull=1#post181609
It refers also to the github of the test program including some results
 
Last edited:
Hi Walter, hi Frank,

yes, I can confirm:

SGTL5000 overclocking with 234ksps and 281ksps works nicely [I use those sample rates frequently for receiving wide band FM stereo broadcast stations with the Teensy Convolution SDR]. However, the processor load is about 79% when using stereo FM radio reception and 234ksps. With 281ksps, only mono reception is possible, because of the high load of the atan2f calculations for FM demodulation.

352ksps does not work, I can only hear noise in my SDR application. Probably its not the processor load, but the codec!?

Have a nice weekend,

Frank DD4WH
 
DD4WH said:
Hi Walter, hi Frank,

yes, I can confirm:

SGTL5000 overclocking with 234ksps and 281ksps works nicely [I use those sample rates frequently for receiving wide band FM stereo broadcast stations with the Teensy Convolution SDR]. However, the processor load is about 79% when using stereo FM radio reception and 234ksps. With 281ksps, only mono reception is possible, because of the high load of the atan2f calculations for FM demodulation.

352ksps does not work, I can only hear noise in my SDR application. Probably its not the processor load, but the codec!?

Have a nice weekend,

Frank DD4WH
Click to expand...

ATAN2: Don't know if this is faster or better - and it is from 2012 - but might be worth to take a look :) : https://www.mikrocontroller.net/topic/atan2-funktion-mit-lookup-table-fuer-arm
 
Awesome!!!!

That specific atan2 approximation lowers the processor load in FM demodulation from 40.6% to 28.15% (234ksps sample rate) and in the first tests I cannot hear the difference between atan2f and arm_atan2_f32!!!

Also in synchronuous AM demodulation mode (SAM) it saves a few % (59 vs. 63% processor load at 100ksps sample rate).

Thanks a lot Frank for that valuable hint! I previously tried two other different atan2 approximation which were much lower in quality and also higher in processor load!

This could have the potential to make RDS decoding possible!?

All the best,

Frank DD4WH
 
Hi Mike,

thanks for your pull request treating EEPROM.

Sorry, I messed up the github (github is not one of my strengths, I must admit . . .).

There seem to be problems with your code:

* some variables that are changed are not saved
* others are saved
* when running for the first time, it seems that there are strange side effects such as missing audio that I cannot interpret at the moment

So, for now, I decided not to pull your code to the github.

Now I have to repair my EEPROM configuration to get the SDR running again, because when I revert your changes in the code, the EEPROM load does expect the old configuration . . . But you added two variables and changed the EEPROM address, so one has to completely setup the whole thing as if it were the first time (well, my fault obiously ;-))

edit: It also had a good side! I discovered a bug in the frequency calibration of the LO, which will be fixed in the next days.

All the best, Frank DD4WH
 
Last edited:
Frank,
I'm not the greatest with GitHub either:) , but I think the procedure is to create a new branch to add somebodies pull request to. That way you don't mess up your current stuff and if you don't like what they did you can switch back to your current branch. It also looks like you are only using GitHub on the web, but not on the desktop or command line?

Sorry about messing up your EEPROM. The way it is now it should be like your starting fresh. The problem I had with introducing the new changes is that there is no way to know if the current EEPROM data is valid, since there is no ID. I added the version and crc to the end. All the data before that would still be valid, if it existed, but I ignored that and overwrote it with whatever happens by the end of setup(). Ideally valid defaults should be loaded from hard-coded at start up and used to initialize everything. Then the EEPROM_LOAD() can check if any saved eeprom exists and update if required. As it is the assumption on my part is that by the end of the setup() all the data is valid. This corresponds with the way you currently handle first use. Perhaps you are not initializing everything by the end of setup?

I haven't changed the EEPOM address, it's still zero. Maybe I should change it to the next up non-interferring location and give the user a chance to use the old data if its valid or the defaults. I'm going to change this to handle version changes and reading the existing current version.

I haven't altered wherever in the code you save to the EEPROM. Don't see how data could not be saved on my side with the crc check and all. If your looking at it with a terminal it prints when saved ect. Think there is still some issues with your code since the last change. As mentioned way back, I don't have the radio hardware, just the display, but it's no longer showing movement and signals on the display as it was before your last change.

thanks
 
Hi Mike/bicycleguy,

integrated your eePROM code into the current version today. It now works properly, I think! I used a brandnew fresh T3.6 to test this and everything worked out nicely (after I eliminated some bugs caused by me that became apparent only with your new eePROM solution ;-)).

Thanks a lot again for your efforts and sorry that I did not integrate them properly using github. I also changed my github setup now and now also use the command line git shell for the Teensy Convolution SDR.

Keep up the good work and please test the new version, if you have the time!

Have fun with the Teensy Convolution SDR,

Frank DD4WH
 
An eMail to me:
>>>>>>>
RX at Teensy 3.6
Wolfgang Hello!

I experimented with the receiver on Teensy 3.6 and noticed problems with the work of AGC.
1. If you move to another area and then go back, the work of the AGC actually disappears. The same applies if you switch between menu items or demodulation types. When you return to the previous section, you notice that the AGC is no longer working.
However, it is necessary to go to the menu item AGC slope, AGC decay, AGC Thresh, AGC mode and only slightly change (change only one of these parameters back and forth) one of these parameters - the work of AGC will restored. This is an unpleasant phenomenon, because without AGC, the noise level rises sharply.
2. The parameter Spectr offset must be set to 10 ... 12 units by default and this parameter is also recorded in Eeprom. Now it has a value of zero and almost nothing is visible in the panorama until you increase it to 10 ... 12 or more. In Eeprom the installation is not recorded now and after switching on each receiver the spectr offset has to be set again ...
3. The time and date settings are not required like the clock on the display since they have to be set again after switching off and switching on the receiver. Teensy 3.6 has no battery to save real time. If you try to set the date, the controller freezes and helps to leave this state. Restart only the power supply.
4. Artifacts around the ADC and DAC lines are observed on the display - the lines around the measuring thermometers disappear. It only helps to change demodulators in a circle. When we return to the previously selected modulation, the rulers are restored.
5. There are artifacts and numbers = 22.5 dB - many numbers are superimposed and the data can not be read.

Can anything be done about the problems identified, especially the work of the AGC?


73! Valery YL2GL
<<<<<<<<<<<<<<<<<

Hello Frank, can you help, please?
 
Hi Wolfgang,

I am happy to help, but not in "second hand mode", so Valery should post his questions here directly on the forum.

My suspicion is that he operates the Teensy Convolution SDR without an antenna or with inadequate hardware, but we do not know and he has no chance to answer our questions, so please tell him to communicate here directly in this thread.

re 1.) AGC: this sounds like a problem with no antenna connected. IMPORTANT: the AGC threshold has to be properly adjusted, otherwise the AGC will not work properly! The Teensy Convolution SDR has one of the best AGC systems of all SDRs (designed by Warren Pratt), BUT: you have to understand how it works and how to adjust it.
Follow precisely the instructions here:

https://github.com/DD4WH/Teensy-ConvolutionSDR/wiki/AGC-(automatic-gain-control)

2.) sounds like a signal level that is much too low due to no antenna connected or an antenna with a very low signal level (short wire antenna?). However, my plan is to make the offset adjustable for each band and save these settings to EEPROM in order to be compatible with all sorts of different antennas and their different signal levels

3.) add a 3.3V battery to the appropriate Teensy pins and you will be able to have the exact time every time you switch on your radio ;-)

4.) have a look at the code and disable the ADC/DAC displays (comment #define USE_ADC_DAC_display) and recompile (their purpose is only for hardware checking!!!)

5.) yes, that happens if the IQ test fails (because you have a faulty hardware OR you have NO antenna connected)

And the last point, probably most important: Use the latest firmware version, because there have been many important changes and bugfixes recently!

https://github.com/DD4WH/Teensy-ConvolutionSDR

Have fun with the Teensy Convolution SDR, 73s

Frank DD4WH
 
Hi Frank!
Here Valery YL2GL.
Thanks for the great design!
I use a 80/40 meter full dipole.
Regarding the work of the AGC - it works perfectly with a great opportunity to select all its parameters. But ...., there is a bug somewhere in the program itself - I listen to the LSB amateur station at 80 meters, the AGC works fine, then I want to change something in the "upper" (on the display) menu, switch to it with the encoder and, in this time, the parameters of the AGC work are changing, which should not be in real life .... I wrote about this to Wolfang ... Interestingly, is it just me or is this effect for someone else?
The same picture, if I, listening to an amateur station, switch types of demodulators in a circle and return to the previous type of demodulation - the AGC settings lose, the noise of the broadcast increases sharply.
But .... if you go to the lower menu (on the display), find any of the AGC parameters, and change at least one of them even by 1 unit, then the AGC operation is restored. Again, the noise is reduced and the reception of radio amateurs becomes comfortable.
Regarding the disappearing lines of the ADC/ DAC graphs, this is a very useful and pleasant function and I would not like to be left without it .... If you switch the demodulators in a circle and then return to the SSB (LSB, USB) reception, the graph lines are restored on the display. This is some kind of bug in the program, I think ....

I tried to be a beta tester of the program, maybe this information will be useful to you.
http://yl2gl.ucoz.net/news/sobiraem...nik_na_baze_modulja_teensy_3_6/2019-03-15-146 - my site with DSP RX at Teensy 3.6 (unfortunately, only in Russian ....)

73! Valery YL2GL
 
Hi Valery,

nice to hear from you and thanks for your report!

However, I tested the situation with the AGC and I cannot confirm the behaviour you describe. The AGC works fine and similarly in the situations you describe. I tried the following:

* sample rate 96ksps
* 80m band, demodulator in LSB
* tune to a frequency in the 80m band where there is NO signal
* adjust AGC thresh so that AGC text just starts to appear
* tune to a ham radio SSB signal
* the AGC text appears and the AGC starts to work
* then turn encoder to switch to menu1
* AGC still works as expected and does not change
* turn the other encoder so that AGC thresh can be adjusted again
* AGC works as expected and does not change
* press mode change button and turn on USB
* turn on LSB again
* AGC works as expected again

So, did you perform exactly the same steps as I did or is there something that you did differently ?

Do you use the latest version from github? You have to use that version because otherwise we cannot compare our experiences.

For the ADC/DAC levels to disappear you must take the latest version and compile it with the respective line commented.

Thanks for the link to your site, with Google translator Russian-English it is indeed readable for me ;-).

All the best 73s, Frank DD4WH
 
Hi Frank!

Thank you so much for the clarification.
I read about setting up the AGC before that, and I did it all, but alas ....
I see that this is not a matter of the settings AGC, since no manipulations in the menu (except AGC) should affect the AGC parameters.
I’m not sure if I have the latest version of the software - Wolfgang earlier helped me with the compilation of the source code for two options of the reference frequency Si5351 - 25 and 27 Mhz. For which he thanks a lot!
And even they work differently .... In the 25 MHz version, the auto calibration passes every time, and in the 27 MHz version - not always ....
It is quite possible that the effect I have noticed is manifested when using large antennas with large levels of received signals - more than 9 points on the S-meter scale (for example: -60 dbm or less).

To increase the popularity of the project, can you download the compiled * .hex files of all (and new) software versions somewhere? With corrections and upgrades ....
Unfortunately, not all are well able to work with source codes in view of their low competence in programming and, even, age .... I, too, am more "an expert" :) in hardware than in software ...

Frank, and in order to compare our versions of the software, can you send me your compiled file for the 25 MHz reference frequency to my e-mail address? Or here, if possible ....
Then I can check the version of firmware I’m using...
yl2gl(at)inbox.lv


Thanks and 73! Valery YL2GL
 
Last edited:
Hi Valery,

please learn how to use the Arduino IDE and Teensyduino in order to compile your programs by yourself!

That is really vital and important and will help you a lot for your own experiences ! [and it is FUN to do so ;-)]

I have uploaded a 25 MHz HEX version for you to test in github.

But I will NOT do that on a regular basis. Everyone can take the ino-file and compile his/her own version whenever he/she wants :). It is really really easy !

Have fun with the Teensy Convolution SDR,

Frank DD4WH
 
Hi Frank!

Sorry, but your hex file doesn't work for me .... It is likely that it is for a different reference frequency, not 25 MHz ....

73! Valerij YL2GL
 
Installed all the programs, installed the necessary libraries , replaced the files according to message # 15 from Canoe, but from the description it is not clear how to change the file - arm_math.h (insert - in which place?, comment - as....)
It would be better to get the finished file with the changes, so as not to be mistaken ....
I'm just a beginner - do not judge strictly .....
 
Hi, Frank!

Regarding the radio-signal reception of WHF - can it be done so that when this demodulator is turned on, the Sample Rate will set 192k by default? We have to search 192k in the menu for a long time....

And need to disable the LPF filters when we turn on this demodulator WHF - for bypass.
I understand that there are not enough controller ports, but you can use, for example, pin3, on which a logical level will appear when the WHF is turned on ....
But this level should disappear at pin29 above a frequency of 30 MHz.
Or disable all logic levels at the outputs of the control of LPF above 30 MHz and simple logic on the 5-OR chip, after this frequency, will turn on baypass for WHF.

And there is an error in the Teensy Convolutio SDR pinout list.
26pin - LP Filter Band 1 (<320 kHz)
27pin - LP Filter Band 2 (320.....930 KHz)
31pin - LP filter Band 3 (930...1975 KHz)
30pin - LP Filter Band 4 (1975....5375 KHz)
29pin - LP Filter Band 5 (5375 KHz...37000 KHz)

Check it.

73! Valery YL2GL
 
Hello, I'm about to make a circuit board for the SDR.
During my research I discovered this preselector, which I like because it doesn't use relays, doesn't need adjustment, and only uses SMD components:

https://www.helitron.de/dj0abr/german/technik/dds/sdrrx_pre4.htm

I don't need the TX path and want to leave it out. I don't need the 630m filter, too.

For switching the filters a ULN2003 is used.
My questions:
I would like to exchange this for an I2C expander, the PCF8574. But according to the data sheet it can only handle 5V - and I'd rather use only 3.2 Volt. The filter is operated with 12 Volt. Is there any important reason for this? (The diodes maybe?)

I think the resistors R1 and R18 have to be adjusted for 3.2V - is this correct?
Why do these resistors have different values?
The filters themselves have 100Ohm resistors built in - do they also have to be adjusted?

sdr_pre4_1big.png


Thanks a lot!
 
Frank B,
I'm no RF guy, so hopefully you'll get more knowledgable responses.

Can't explain R1, R18 difference. From data sheet PIN diodes D2... have about .9V across them so ignoring inductors, (12-.9)/(100+470)=19mA, other side would be (12-.9)/(100+220)=34mA. Not sure it would make a difference so I guess an error.

Guessing you want at least 10mA through diodes so (3.2-.82)/.01=238 ohm so maybe keep the 100 ohms and change R1 & R18 to 100 ohm.

Don't see the problem with PCF8574 at 5V but the pull down currents are close. Two diodes get pulled down in parallel so close to the 25mA typ. but over the 10mA minimum. If you don't use all 8 channels you can parallel them for more current.

Will your circuit board be the RF only or include the Teensy3.6? 4?
 
Hi Frank,

I have no experience with PIN diode switching, but they are said to have low resistance against IM3, which means that high signal levels can seriously distort your reception. Could be that you can improve that with higher voltages driving the diodes, but I cannot help with that due to my missing experience in that field.

Preselection for the Tayloe / QSD - SDR-frontend is tricky. You need at least 50dB attenuation at three times the Receive frequency and your filter passband should not attenuate too much. I have simulated one of the filters of the schematic you gave with ELSIE (using realistic Q values for SMD Ls [30] and SMD Cs[200]).



As you can see, attenuation at 3xRx freq is about 45dB [Rx = 7MHz, 3x = 21MHz], which could be enough! But you can also see, that in the centre of the passband, the passband attenuation is more than 7dB !!! That hardly acceptable from my point of view. And this is for a perfectly RF-optimized PCB design and does not take into account any effects of the diodes . . .

I doubt that we would need a bandpass, a lowpass should be enough (but should be able to provide >50dB of attenuation at 3x the Rx frequency), because the attenuation of the Tayloe frontend at 1/2, 1/3, 1/4 the Rx freq is much higher than at odd mutiples of the Rx freqs.

Have a look at this frontend [you would have to recalculate all the filter values for your desired input/antenna impedance, eg. 50 Ohms]:

https://www.box73.de/file_dl/bausaetze/DK5DN_FiFi-Preselektor.pdf

All the best,

Frank DD4WHFrankB frontend filter.jpg
 
You must log in or register to reply here.
Back
Top