TEENSY SDR .....no compile code

[max-232]

Hello ...I try construct one teensy HF sdr transceiver... buy one teensy 3.2 board, audio board and si5351 DDS board and my sdr board is from YU1LM....very good sdr whith Powersdr software and PC, and is very simple for construct.
I try compile the Rich VE3MKC code whith arduino IDE 1.6.7 and Teensyduino 1.27, but I have many errors of complile.
I put in teensyduino mode on the configuration of arduino ide and select the teensy 3.2 board and 72Mhz clock and correct com port.
Try the wa2vfn code and many errors....
I not a guru of teensy but I have work whith arduino codes and no problem.

Please is posible help me.:)

Thanks for all.........73....Mario....EA7IXD.

[Frank B]

At least, post the errors you see...

[PaulStoffregen]

Is this the code?

https://github.com/rheslip/Teensy_SDR

Generally you need to follow the "Forum Rule" for help here. If you're compiling code from some website without any changes, it's enough to give us a link to the code. But really, do you expect us to guess which code you're using from only "the Rich VE3MKC code"?

[joedarock]

I've also been having difficulty compiling the code at https://github.com/rheslip/Teensy_SDR. I'm running Arduino 1.8 with the latest Teensyduino installed w/no problems. When I attempt to compile, I get about 100 warnings and errors which I'd gladly post here if everyone is OK with such a long post. Or maybe there's another way to include the error output?

Someone please advise how to proceed.

Joe

[Frank B]

I've also been having difficulty compiling the code at https://github.com/rheslip/Teensy_SDR. I'm running Arduino 1.8 with the latest Teensyduino installed w/no problems. When I attempt to compile, I get about 100 warnings and errors which I'd gladly post here if everyone is OK with such a long post. Or maybe there's another way to include the error output?

Someone please advise how to proceed.

Joe

Please attach the output as .txt - file.
thanks.

[el_supremo]

I tried to compile the Teensy_SDR code and there a re a large number of errors like this:

filters.cpp:5: error: narrowing conversion of '2.84086189e+1f' from 'float' to 'short int' inside { } [-Wnarrowing]

They are all caused by the inclusion of the filter coefficients which are like this, for example,

32768 * 428.8698225779810E-18

The problem is that this constant is being included in an array of short integers and the compiler is having indigestion. It can be fixed by editing each of the six offending .h files and changing every entry so that it looks like this:

(short) (32768 * 428.8698225779810E-18),

I have edited all six files and with this fix, the code compiles. I've attached a zip archive of the 6 edited files.
Teensy_SDR_h.zip

Pete

[Frank B]

Yup, as far as i know -Wnarrowing is "new" and wasn't present in older gcc versions.

[joedarock]

That seems to have fixed it...thanks!!!

Joe

[joedarock]

I'm curious how/why this works. It seems that the result of the multiply is a larger number than can be cast into a Short, unless:
1) A Short in this compiler is 4 bytes
2) Some precision is lost when the result is cast into a Short

Educate me please

Postscript: I failed to see the E-18 exponent so it appears that the cast has to result in a 0 value in the Short. Am I looking at this correctly?

[el_supremo]

Some precision is lost when the result is cast into a Short

That's the explanation - short is 16 bits. As you said, some of the numbers are going to end up as zero.

Pete

[joedarock]

In looking at the coefficients, it appears that, not only will some values cast to zero, many of the others will be severely limited in resolution. Do you know if there was a reason why the code not written to scale the coefficients with a larger number than 32768 and then cast into Longs?

[el_supremo]

The audio library uses 16-bit integer arithmetic - the samples produced by the audio board are signed 16-bit integers.

Pete

[joedarock]

Aha! In looking through one of the Hilbert coefficients listings, I see why they're not scaled against a larger value. Some of the coefficients in the file I'm looking at go up to 0.87, so scaling against any larger value than 32768 would possibly overrun a signed 16-bit integer.

Any idea why the library doesn't use longs in the calculations then down-scale to 16 bits, which would allow many more of the smaller coefficient values to be significant in the calculations?

[defragster]

... Any idea why the library doesn't use longs in the calculations then down-scale to 16 bits, which would allow many more of the smaller coefficient values to be significant in the calculations?

Not sure which 'calculations' are at hand - but the Audio library works well and fast by using custom MCU operations where 16 bit math is done in parallel in a single 32 byte word. Without that 16 bit limit those operations can't be used and the efficiency would suffer.

[joedarock]

Thanks for the insights.