• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 684 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294NCPDT: ADC sample code for capturing AC Voltage frequency

ronnie
Prodigy 140 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: TIDA-01088


Hi

I am attempting to use the ADC to capture the stepped down voltage waveform parameters of our local AC Supply.

On the scope, it is a 50Hz +/- 1V sine wave at the ADC pin.

Wondering if anyone has sample codes to share for capturing frequency and Vpk ?

  • 0
    TI__Guru*** 133065 points

    Hello Ronnie,

    We have an ADC example for simple operation of it in TivaWare under the peripherals folder. It's titled single_ended.c. Start there and adjust the polling interval in the while loop so it checks at a rate larger than 100 Hz (200 probably would be good probably), and see how that works and if you have further questions, clarify what is still not quite working as you want.

  • 0
    Guru 117855 points

    ronnie said:
    On the scope, it is a 50Hz +/- 1V sine wave at the ADC pin.

    In addition to the vendor agent's guidance - you must insure that your AC Signal is sufficiently 'voltage-level offset' - such that the waveform's negative descent (its trough) never drops below the ADC's 'Minimum Voltage Input Specification.'   (0VDC)    If your input signal (really) drove 1V below MCU Gnd - that is a serious 'MCU Spec Violation!'    ALL portions of your 'AC input signal' must remain  ≥  0V and ≤ 3V3' - to comply w/the MCU's ADC specification.    (some here may claim that the 'positive half of the AC envelope may reach to 5V' - my belief is that (in time) such 'excessive inputs' likely prove damaging - and perhaps of more importance - the ADC is 'BLIND' to signals above 3V3 (reporting them as only 3V3) - thus such practice is risky & w/out (any) measurement  merit!

    There's no mention of 'Desired Accuracy.'    Should accurate 'V_Peak' measure be your objective:

    • you may have to reduce any 'waveform filtering' - which would absorb (thus mask) any voltage peak
    • and raise the sampling frequency to 'heighten the odds' that at least (one) of your voltage captures occurs at/around V_Peak   (suggest 8x50Hz)

    Via an external (or internal) Analog Comparator - you can determine the AC Signal's frequency by its, 'Passage thru the Signal's 'Mid-Voltage Level' Point.   The external comparator enables eased 'Hysteresis' - insuring sharp output signal transitions - vital for such robust measurement.    And your 'IP' is then instantly 'Re-Usable' - if & when you graduate to a 'Named' rather than 'other' MCU...

    BTW - if an analog comparator is 'in play' (better still a 'R2R' Op-Amp) -  it is then possible to implement a classic, hardware, 'Voltage Peak Detector.'     This proves superior as it  enables the proper 'capture' of the peak voltage - while avoiding the demands imposed upon the ADC - by high Nyquist sampling rates!    (and which (still) - cannot  guarantee the capture of the 'Absolute Peak Voltage' - as you have (only) a '±11° window'  -  centered upon the sine-wave's '90° V_Peak' - to achieve  ≥98% accuracy!   Error arrives quickly/forcefully - 'outside' of that '11° Peak Measurement Window!')

    Note too that the hardware peak detector has a 'built-in' sample & hold feature - greatly reducing (i.e. likely eliminating) the  aggressive timing demands - forced upon the 'ADC-alone' method - previously proposed.

  • 0 in reply to cb1_mobile
    Prodigy 140 points

    Hi cb1_mobile

    Thanks for reminding about the pins -ve limitations. 

    I checked and it was OK. The DC offset and the AC combined is between 3V and 0V and is within the acceptable range.

    I was hoping there is a standalone function that can perform the frequency and peak voltage computation.

  • 0 in reply to ronnie
    Guru 117855 points

    Thank you my friend - it is not always that 'helpers' receive thanks - especially when they are (FAR from) vendor agents.

    Note that there 'are' protective structures w/in the MCU which attempt to 'absorb' Voltage Range Violations.   These elements are tiny - and are (not) intended for 'long-term' voltage absorption.   Current always must be limited - if one relies upon these (protective/ESD) elements - yet considerable investigation has revealed that (occasional) rather than (continual) use - proves 'best' for these pin's survival...

    To your 'hope' for a, 'Packaged Solution' (aka 'standalone function') - this vendor has chosen (not) to, 'Deprive you of the joy of 'Self-Solution.'    Consider too that you have, 'Cast your Solution (only) w/in the bounds of the MCU's ADC.'     When measuring 'frequency' - would not your use of the MCU's extensive Timers - prove (both) faster & easier?     (Pardon - yet poster directed 'solutions' - do (not) always - prove best or even workable ... solutions.) 

    Frequency Measurement Helper:  

    As the earlier post noted - your employ of an 'external analog comparator' will enable your detection of the signal's passage through (above & beyond) a pre-set trip point. (determined by a simple '2 R - Voltage Divider')     When the comparator's output is fed to the MCU - an 'interrupt' may be generated and/or an MCU timer may 'Log the (near) exact time' of that event.    Then - the very next (identically generated) comparator output - may be similarly 'captured/logged' - and the difference in values between the two - as you know - relates (inversely) to the frequency.   (larger timer 'deltas' (differences) indicate lower frequencies)    Don't you (now) agree - that such use of the MCU's timer (or 2 timers) trumps the ADC - for such frequency measurement capability?   

    Possibly interesting aside: Unless you could, 'Force your ADC to measure at 'Precisely known "Points in time" - and then search/scan for (near) identical ADC values (which suggest that you (may) be measuring at (near) identical (repeated/following waveform points) - I don't know how you'd 'tease such capability' from the MCU's lowly ADC!     Rather clearly - the above 'Timer Method' seems a superior solution.    Your 'hoped for' (and vendor approved) ADC method ... serves instead as a, 'neat torture vehicle' for my young, uber-bright staff - when they 'over-reach!'   (which is all-day - every day...)  

    ADC Measurement Helper:

    Another's suggested mini-file (single_ended.c) followed the 'ten foot rule' (did not come w/in 10 feet) of your 'V_Peak' measurement - is that not true?   

    • What's really important for such an accurate (Point in Time) analog voltage capture?   
    • How do you 'capture' the input signal's PEAK - which one here identified as being, 'Centered w/in a ±11° window' - referenced to the input sine-wave's 90° waveform point?   

    In (maybe) the answer to these questions:

    • How do you propose, 'Syncing your ADC' to the (near) sine-wave input signal?'   
    • Can one even achieve this?   
    • And if so - what degree of accuracy & precision (repeatability) is reasonable?   

    You made, 'No mention of the earlier suggested, Added hardware 'Voltage Peak Detector' - which has been presented as 'VASTLY SPEEDING/EASING/ENHANCING' (how good that!) - your desire for 'V_Peak Detection, Capture & Eased Measurement.'     The addition of such hardware (although not required if the MCU includes a 'reasonable' op-amp as a feature) spectacularly SIMPLIFIES your ADC's measurement - as 'Substantially all 'Time Constraints' upon your ADC Capture - are eliminated!   (i.e. the hardware 'Captures the Peak - and then 'holds it' (for a reasonable duration).

    Vendor's 'ever expanding To Do List' - is unlikely to include such 'Stand-Alone' functionality - yet maybe - we'll be surprised.    My intent here is to (hopefully) stimulate your thought & consideration - often beyond the, 'Too narrow constraints of 'Always & Only' ... the MCU as 'total solution!'     Instead - the 'Strategic Combination of (both) MCU & select hardware' - more often than not (as clearly illustrated here) - proves best!   Re-Usable hardware maintains its rightful place - in all but the 'highest volume applications' - and (very) few of those will arrive here...

  • 0 in reply to cb1_mobile
    Prodigy 140 points

    I saw your suggestions to add in hardware detection circuits to aid in acquisition of the frequency. 

    I appreciate your consideration to simplify the effort to get the frequency rather than doing very fancy algorithms but 

    looks like I am stuck with the ADC method as the boards are already "tagged" for mass deployment.  :(

    Its ok  though , I believe I will be able to scavenge something out from a couple of references such as TIDA-01088.

  • 0 in reply to ronnie
    Guru 117855 points

    My friend - again thank you for your response & kind award - always appreciated.

    While, 'Tagged for mass deployment' - does that not suggest that, 'Early rather than (far) later - arrival to market' proves critical?    Will not the 'pressure' become enormous - as weeks pass - and the 'overly complicated' (in my experience) method adopted (always/only the MCU's ADC) - 'borders upon being 'over-challenged?'   

    There are other critical items to consider - as well - when 'mass deployment' is an objective.   The ARM Cortex group of MCUs include: M0, M0+, M3, M4 (those here) and M7.    Now (both) the M0 & M0+ devices achieve (notable) cost-down!     (which defines their 'raison d'être!')    They also are available in smaller-sized packages - which enables board-size reduction - further reducing cost.

    It just may be - that such 'Broad/Strategic Thinking' - may (again) 'Enable Design Objectives to be met w/in a, 'FASTER, EASIER & ENHANCED' manner' - so vital for 'mass deployment.'    (And also - for more 'reasonable' (lower) Sales projections' - where, 'Early & Successful ARRIVAL TO MARKET' - enables 'Highest Profit Margins' - while those (struggling) w/'Premature Optimization' (MCU ONLY attempts) - arrive (too often) LATE  (or never) - and to vastly reduced margins - along w/entrenched competition!