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

Thread: Changing ADC Reference Voltage for Audio Library

  1. #1

    Changing ADC Reference Voltage for Audio Library

    Folks,
    Does anyone know how to change the reference voltage for the audio library from 1.2 to 3.3V? I am using it for non-audio projects and need to take inputs with maximum dynamic range.

    Any help would be appreciated.

    Thanks,
    Greg

  2. #2
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,174
    In that case, not using it for audio, the ADC library which allows to switch the reference voltage, sampling speed and rate, averaging, and so on, would probably be better suited.

  3. #3
    Thank you for your kind response. However, it is the solid FFT and filter routines of the audio library that makes me stick with it, and I'm well aware of the various ADC functions and libraries out there. I am exploring designing a broad-band, heterodyned FFT (PSA architecture) spectrum analyzer based on the Teensy 3.6 and that library. For me, and anyone else who might want a 3.3V full scale rather than 1.2V, that gives you more than 8 dB of additional dynamic range above the Johnson and other inherent noise sources.

    I was hoping it would be a simple matter to adjust that one thing, then the rest is all great! It should be possible to heterodyne the FFT range of about 20 kHz to nearly anywhere within the range of the chosen analog multiplier (easy to get several MHz, possible to go to a few hundred MHz).

    Thanks,
    Greg

  4. #4
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,174
    In the audio library, open input_adc.cpp and change line 51 to
    Code:
        analogReference(DEFAULT); // range 0 to 3.3 volts
    or, when using the stereo input object, open input_adcs.cpp and change line 61 in the same way.

  5. #5
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,246
    You can simply call analogReference() in setup(), too - the audio-objects get initzialized before setup(). So calling analogReference() should change the reference, in theory (not tested). This way you don't need to edit the library.

  6. #6
    Quote Originally Posted by Frank B View Post
    You can simply call analogReference() in setup(), too - the audio-objects get initzialized before setup(). So calling analogReference() should change the reference, in theory (not tested). This way you don't need to edit the library.
    Unfortunately, this approach did not work.

    I was hoping not to have to edit the library so that I could share the project widely. New users (I have taught for a long time) often are intimidated by editing libraries, and then when the parent library is updated by the author, have to do it again.

    It's just odd (to me) that there is no easy option to change the reference voltage (i.e., full-scale range). I might be missing it though.

    I will think about work-arounds, but any suggestions would be welcomed.

    Thanks,
    Greg

  7. #7
    Thank you very much. I replied to Frank B that when a project is intended to be shared (e.g., with students who may be just starting), editing libraries can be intimidating. Also when the parent library is updated, the process must be repeated. I find that begging the library authors to add a feature works better.

  8. #8
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,246
    hm, try to insert a short delay before changing the reference. delay(10) is enough.
    if that does not work, too, I'll look what's wrong with this approach. please report!

  9. #9

    Hoping for Library Additions to Broaden User Base Opportunities

    Quote Originally Posted by Frank B View Post
    hm, try to insert a short delay before changing the reference. delay(10) is enough.
    if that does not work, too, I'll look what's wrong with this approach. please report!

    Will do. Have not been at the computer.

    I hope Paul Stoffregen will see this. Two changes to the library would open it up wide for folks doing teaching and science. One is to use the full 3.3V swing. When using the native Teensy 3.6 ADC inputs, there is a LOT of noise with the input in question grounded to AGND. One spike mid-range maybe 50 dB down, then gradually rising noise for the top 1/4 of the bins. In this mode, one gets only about 8 bit ENOB, maybe 9, and the audio shield is not a solution for those who need to go down to DC (anybody doing biomedical or scientific work). On our end we could engineer a good DC-coupled ADC add-on (a PhD student of mine led the team that built a really good DSP shield for Arduinos: https://web.stanford.edu/group/kovac...age=dsp-shield).

    The second would be allowing the user to modify the sampling rate. This would be super helpful.

    If those things could get built into the library and thereby updated as it is improved over time, it would be a true blessing to the community.

    Thanks!
    Greg

  10. #10
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,174
    Basically, everything you want can be already done. You'd naturally not have the advantage of using the audio library (in fact, it's called "audio" and not "DC" or "biomedical") but you'd need to write some more lines of code by yourself. But also this proceeding has its general limits when it comes to ADCs and DACs "on chip" inside a micro-controller because supply, ground and references will always be somewhat "dirty". A more professional approach for biomedical applications would be to have a separate analog board with dedicated and optimally selected ADC(s) and DAC(s) for the specific use case and a separate linear regulated power supply for it. Then, through a galvanic isolation via high speed optocouplers, the data would go towards and from the Teensy which could explicitly care about the signal processing, filtering, FFT and whatever you want.

  11. #11

    Understood... Request Still Stands - Please Read

    Quote Originally Posted by Theremingenieur View Post
    Basically, everything you want can be already done. You'd naturally not have the advantage of using the audio library (in fact, it's called "audio" and not "DC" or "biomedical") but you'd need to write some more lines of code by yourself. But also this proceeding has its general limits when it comes to ADCs and DACs "on chip" inside a micro-controller because supply, ground and references will always be somewhat "dirty". A more professional approach for biomedical applications would be to have a separate analog board with dedicated and optimally selected ADC(s) and DAC(s) for the specific use case and a separate linear regulated power supply for it. Then, through a galvanic isolation via high speed optocouplers, the data would go towards and from the Teensy which could explicitly care about the signal processing, filtering, FFT and whatever you want.
    Thank you for your thoughtful response. I'm not trying to argue, just make my case as an educator.

    Believe me (28 years as EE professor) I truly do understand substrate-coupled noise and other reasons why ADC's on uP's do not deliver full performance (effective number of bits). In this case, however (Teensy 3.6) the measured ENOB in general use is much better than what I'm seeing here, typically 12+ bits. This is best measured by introducing a nearly full-scale pure sinewave (we use an SRS ultra-low distortion source) and exporting the captured data.

    In any case, we totally understand biomedical instrument design (ECG, EEG, pacemakers, etc.) from decades of hands-on work. That's not at all the point. The point is that there is a well-known, easy-to-approach (put yourself into a freshman student's shoes) audio (clearly understood) processing library that would be awesome for general educational purposes with probably a small amount of time invested into the library code. So, to be clear, the point here is not "professional," but "educational."

    There is no well-documented, easy to approach toolkit like this that does not require additional hardware. If you follow my previously posted link, it shows a pretty high-performance DSP shield for Arduino with another optional shield that provides DC-coupled, 4-channel I/O at high ENOB. The problem is that it is too expensive for the masses, hence my request for help from the community.

    Just FYI, I have an open-source design for a Teensy 3.6 driven board with 24-bit differential ADC that delivers nearly the full ENOB at 144 s/s and early next year will release one with touchscreen, GPU, WiFi and clean analog supply. All are low-cost... the point.

    Thanks,
    Greg
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	IMG_7832.jpg 
Views:	5 
Size:	161.1 KB 
ID:	15465  

  12. #12
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,174
    Please accept my apologies. It was for sure not my intention to tell you how to do your job, but from reading what you wrote before, I wasn't able to see that you were definitively looking for a cheap and simple solution for educational purposes. For me, when you wrote about students having difficulties in modifying a library, it sounded rather like a general example.

    Since Paul Stoffregen is actually more than occupied with beta testing and bringing a new product to market, it might be (I can naturally not talk in his place) that extending the audio lib is at this moment not very high on his priority list. A quick fix could be that you or someone commissioned by you fork the audio library, add the desired modifications, so that you have your "Stanford branch" as needed and you can start your project work. After some testing, you could make a pull request which would allow Paul to merge your functions into the main branch which finally would allow conflict-free updating. In the (purely hypothetical) case that he'd reject these extensions, you could still update your branch from the main branch without overwriting your added functions.

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,242
    Quote Originally Posted by StanfordEE View Post
    I hope Paul Stoffregen will see this.
    Yup, I see this.

    First, please understand the Audio library and most other libs are in a sort of "feature freeze" at the moment, while most dev work is going into the new Teensy. I'm sure you've seen the beta test thread here on the forum.


    Two changes to the library would open it up wide for folks doing teaching and science. One is to use the full 3.3V swing.
    I had intended to put this into the code some time ago, but never got around to it. So far, the 1.2V range as worked very well for most people.

    The other point to consider about 3.3V range is you're using the power supply as the voltage reference. Teensy 3.x has some VREF filtering for the worst high frequency noise, but in the audio band any noise on the supply can easily couple into the ADC this way. The built-in ADC is already pretty noisy, so I'm a little skeptical this is necessarily a step in the right direction. Nonetheless, when work resumes on this and other libs, adding the ability to change the reference like we have for the built in DAC output (right-side documentation panel) isn't that difficult.


    The second would be allowing the user to modify the sampling rate. This would be super helpful.
    This is unlikely to ever happen on Teensy 3.x, at least as a convenient API provided by the library, because the hardware simply isn't that flexible. Especially the PDB timer used for the built in peripherals offers only integer divisions of F_BUS, which is itself an integer division F_CPU. Between the different Teensy models and different clock speeds available, and the requirement for all the master-mode I/O to run exactly synchronous to the clock (where the other stuff runs from mult+div of MCLK), the result is only certain sample rates are possible.

    When we have Teensy 4.0, the technical trade-offs will be different. There we get a PLL dedicated to the audio, and peripherals that can run asynchronous from the CPU clock. M7 at 600 MHz also offers much more capability for retiming / resampling in the cases where we need to deal with slightly mismatched rates. I always resisted doing this on Teensy 3.x... but after so much pain with various USB hosts doing USB audio differently, I believe that is probably going to be the best long-term solution for USB, maybe SPDIF input too? If you check out the beta test thread, you can probably see we're still quite a ways off from getting to these sorts of very fine details, but you can also see progress is coming along quickly. I imagine we'll be in a good position to really consider these sorts of major structural changes around the middle of summer 2019.

  14. #14
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,174
    Ok, I'd be ready to implement the analogReference() function in the adc and adcs objects and do a pull request to save everybody most of the work.

    When it comes to the variable clock, it is true that the new Teensy will give more flexibility, but we should not forget that there is the downside that it has no internal DACs...

  15. #15
    Oh, il est clair que vos intentions sont bonnes! No worries. I did not have any insight into Paul's calendar.

    We have actually been involved in forking the entire Arduino IDE ("Energia" from Texas Instruments). Whew. Not a good plan here, but if you want to see it: https://energia.nu/

    Actually, this is a great forum and perhaps my students and I could add value with analog and mixed-signal help. Soon, we'll have boards and code ready too.

  16. #16
    Paul,
    Thank you. Your work is treasured by us, and the Teensy 3.X has been my go-to teaching board for years. I have not seen the beta test thread nor heard of the new Teensy. I'll check it out.

    I really appreciate your response. I understand the sample rate quantization due to the hardware, but not why it would be difficult or impossible to allow selection of the period as multiples of some base period, as the IntervalTimer interrupts are done (e.g., 100 us period for 10 kHz sample rate).

    I understand and respect the focus on audio. I was just trying to point out that there is a *huge* other community that likes "near DC" and "RF" and tend to be poor students. I don't want to be a pest.

    FYI, when the dust settles for you, and if you care to hear more, I can tell you about one my PhD students who is making a low-cost, open-source (no liability, don't worry) medical instrument for the developing world based on at Teensy 3.6. It's very, very possible, and we already have a full multi-lead ECG with DSP features up-and-running with the 3.6. Neat stuff, coming soon to Tanzania, we hope!

    Many thanks and Happy New Year!

Posting Permissions

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