Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 15 of 15

Thread: TEENSY SDR .....no compile code

  1. #1
    Junior Member
    Join Date
    Mar 2016
    Posts
    1

    TEENSY SDR .....no compile code

    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.

  2. #2
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,940
    At least, post the errors you see...

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,742
    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"?

  4. #4
    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

  5. #5
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,940
    Quote Originally Posted by joedarock View Post
    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.

  6. #6
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,544
    I tried to compile the Teensy_SDR code and there a re a large number of errors like this:
    Code:
    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,
    Code:
    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:
    Code:
    (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

  7. #7
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,940
    Yup, as far as i know -Wnarrowing is "new" and wasn't present in older gcc versions.

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

    Joe

  9. #9
    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?
    Last edited by joedarock; 04-06-2017 at 05:04 PM. Reason: Further thought on the subject

  10. #10
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,544
    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

  11. #11
    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?

  12. #12
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,544
    The audio library uses 16-bit integer arithmetic - the samples produced by the audio board are signed 16-bit integers.

    Pete

  13. #13
    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?

  14. #14
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,474
    Quote Originally Posted by joedarock View Post
    ... 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.

  15. #15
    Thanks for the insights.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •