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.

MSP430F67791A: line-to-line voltage

Part Number: MSP430F67791A
Other Parts Discussed in Thread: TIDM-THDREADING

Measuring phase-to-phase (not estimating/calculating) is a common function of an energy meter.  The EMDC doesn't support this.  Is there a way to work around or modify the library to add this measurement or is the EMDC library completely locked (ie. better off writing all of the metering functions from scratch)?

Also, there was talk of additional feature releases, but it has been a while.  Will things like THD, demand intervals, etc. be added to this library?

Thanks,

Scott

  • Hi Scott,

    Thanks for your post. I've also replied to your direct message as well.

    S.L said:
    Measuring phase-to-phase (not estimating/calculating) is a common function of an energy meter.  The EMDC doesn't support this.  Is there a way to work around or modify the library to add this measurement or is the EMDC library completely locked (ie. better off writing all of the metering functions from scratch)?

    You're correct that EMDC does not support this feature yet. However, we may add it to a future release depending on the priority driven by customer interest and requests. As mentioned in my direct message, we've been working on adding sag/swell support which can actually be added to the application-level code that's generated by the EMDC GUI. We did not change the EMDC library itself though, so measuring phase-to-phase angles may be possible in the application-level code - we just haven't focused on doing it yet. The source code for EMDC is not shared.

    The TIDM-THDREADING reference design supports phase-to-phase angle measurements. In Section 3.2.3.1.3 of the user's guide, it says the following:

    The samples of the generated pure sine waves are obtained by indexing into a lookup table of sine wave samples. In the software, there is one lookup table, but each phase has a different index into that same lookup table. Based on the value of the lookup table indexes of the different phases, the angle between the different fundamental voltage waveforms can be calculated. In the firmware, the phase-to-phase angle between a phase’s voltage waveform and the previous phase’s voltage waveform is calculated (that is, ɸ13, ɸ21, and ɸ32) . This phase to phase angle variable is internally represented in the firmware as a signed integer and is in units of 180°/215 . Based on the expected value of the phase-to-phase angle readings, it can be determined whether an incorrect phase sequence is being registered by a meter by comparing the expected values of the phaseto-phase readings to the actual measured value. As an example, if ɸ13, ɸ21, and ɸ33 are all expected to be 240° but are reading 120°, this may indicate that two of the voltage connections have been accidentally swapped.

    There may be other ways to implement this using the EMDC-generated code. Similar to what we've done for sag/swell and zero-crossing detection, you can check when the voltage ADC channels go from negative to positive in the SD ADC ISR and use a counter or index to know the number of samples (and hence the phase angle) between the start of each voltage channel cycle per phase. Also, you may be able to implement what was done in the TIDM-THDREADING design in the EMDC-generated code.

    S.L said:
    Also, there was talk of additional feature releases, but it has been a while.  Will things like THD, demand intervals, etc. be added to this library?

    Possibly. We've been focusing on other priorities lately, so new releases have been pushed back. If a release does happen this year, I'll let you know. In the meantime, sharing additional features like you've done is very helpful when proposing for and developing a new release. For example, we've had several requests for THD support, but the requirements have been vague. For example, we have gotten input on the max harmonic but discovered it varies substantially (from 13th to 50th). This is important when determining the minimum ADC sampling frequency for ensuring it's above the Nyquist rate.

    Demand intervals would probably be handled at the application level.

    Regards,

    James

  • James,

    That is unfortunate.   It seems i'm stuck between using the limited EMDC that cannot be modified and likely can't do exactly what i want or using the legacy library that has way more functionality.  Since none of it is really novel invention, i'm not sure why TI would feel the need to lock it.  Extrapolating line-to-line for example assumes a lot of ideals (a pure sine wave as you mention, a perfectly balanced system) which are never the case in the real world.  I find it interesting that you say there is no zero-crossing functionality in EMDC as I thought it does have that feature.  Is there a performance advantage to the EMDC or just the code generation?  I really would prefer CCS, can the legacy library be used on CCS?  Could you point me to any documentation on legacy library, including documentation/API/etc?

    Thanks,

    Scott

  • Hi Scott,

    S.L said:
    That is unfortunate.   It seems i'm stuck between using the limited EMDC that cannot be modified and likely can't do exactly what i want or using the legacy library that has way more functionality.  Since none of it is really novel invention, i'm not sure why TI would feel the need to lock it.  Extrapolating line-to-line for example assumes a lot of ideals (a pure sine wave as you mention, a perfectly balanced system) which are never the case in the real world.

    We've covered this offline.

    S.L said:
    I find it interesting that you say there is no zero-crossing functionality in EMDC as I thought it does have that feature.

    You're correct that EMDC has this feature. What I meant to say is that the zero-crossing functionality is there and is used for things like measuring the AC mains frequency, but we don't have a dedicated output or variable in the existing EMDC implementation that signals when the zero-crossing occurs. We had a customer request this for firing a triac, so we were able to do that at the application level without modifying the EMDC source code. Basically, we checked when the cycle count changed and toggled a GPIO. Nothing fancy but it worked.

    S.L said:
    Is there a performance advantage to the EMDC or just the code generation?

    The code generation piece is an advantage especially when simple things like HW connections are changed but also valuable when things like the sampling frequency is changed. In the IAR-based designs, when parameters like the sampling frequency was changed, everything in the code was hard-coded (e.g. arrays, filters, etc.), so everything immediately broke causing headaches for our customers. EMDC does take advantage of the optimized assembly code for the mathematical calculations (mac, sqrt, etc.) ported from the legacy IAR-based library. That helps improve performance and available bandwidth.

    Hope this helps.

    Regards,

    James