C2000 Office Hours: Have questions on your latest C2000 design? Real-time answers to your questions!

Where are the office hours?  This thread?  A chat?  A video?  

Hi Jut,

The office hours will take place in this thread.   Just come back on the designated date/time and post your question in the thread and one of our C2000 Experts will answer it for you in real-time! 

Mark your calendar!

August 21 – 11am -12pm  CST

August 22 – 3pm -4pm CST

August 23 -  9am – 10am CST

Thanks!

Hi everyone,

Welcome to C2000 Office Hours! I just want to let you know we will be on hand for the next hour to answer any questions you may have.

Thanks.

Patrick

Hi,

I have some questions about the software phase locked loop (SPLL) module from the solar application library in ControlSUITE:

I tried it on the Development Kit, and the sine output of the SPLL was able to lock the phase of its AC input.   The problem is that the value of the angle ' theta[0]' was only between 0 to 1 , instead of between 0 to 2pi.

My AC input is 60Hz, and the spll is triggered at 20K Hz

I modified the code to   spll_obj->theta[0]=spll_obj->theta[1]+(spll_obj->wo*(0.00000795));

according to the posting  " About the Solar Liberary Function of C2000™ Solar Inverter Development Kits "

What is the meaing of   ( spll_obj->wo*(0.00000795) )   ?

If Wo= 2*pi*f,   and  0.00000795 is calculated by delta_t / (2*pi), then the formula above becomes   '  frequency * delta_t '   or delta_t / period '  ?

Hi Frank,

I am initially not clear on the answer to this question; however, I have directly forwarded this question to the team who developed the library and development kit. Hopefully we can get an answer for you here soon.

Patrick

Thank you.

Actually, I have more questions related to this SPLL module. Can I post all my questions here?

Frank,

Definitely, feel free to post your remaining questions here. We will work to get you answers in addition to your original posting.

Thanks,
Patrick

I'm having trouble with the HVBLDC_Sensorless example code on the TMS320F28035 microcontroller.

I have selected build level 1, set the enable bit, and when I pause the debugger, I get a value between 0 and 5 on the MOD6_CNT output variable.

But when I try to measure the PWM outputs, I get nothing. I tried one of the other PWM examples, and I got the expected result on the oscilloscope. So nothing should be wrong with the hardware itself.

Any ideas why it doesn't work on the motor control code? Is there some setting I'm missing?

In the posting  "About the Solar Liberary Function of C2000™ Solar Inverter Development Kits",

Manish Bhardwaj, a TI expert, said the SPLL module in the solar library was designed to handle input frequency changes from 57Hz to 63Hz if the grid voltage was 60Hz.

My first question is :

why is it from 57Hz and 63Hz ? Is this based on any industry stardard ?

My second question is :

How can I modified this SPLL module, so that it will still perform well for larger input frequency changes, i.e. 54Hz to 66Hz ?

Gard,

Could you provide more information? Which development kit are you using?

Patrick

Gard,

Do you happen to have the motor connected?  I believe that the instructions don't have you connect the motor until Incremental Build 2.

The motor control software that you are using has protection via internal comparators peripherals and trip zone peripherals.  I believe that the software doesn't expect a motor to be connected and is tripping quickly because things are not as the hardware expects.


Thank you,
Brett

I don't know if I'm too late now. But I'm using the "C2000 Microcontrollers Development Tools" and the newest free version of Code Composer Studio.

I also have not connected the motor yet. I'm measuring the output on the PWM without connecting it to anything. 

In the posting  "About the Solar Liberary Function of C2000™ Solar Inverter Development Kits",

Manish Bhardwaj, a TI expert, said the SPLL module in the solar library was designed to handle input frequency changes from 57Hz to 63Hz if the grid voltage was 60Hz.

My first question is :

why is it from 57Hz and 63Hz ? Is this based on any industry stardard ?

My second question is :

How can I modified this SPLL module, so that it will still perform well for larger input frequency changes, i.e. 54Hz to 66Hz ?

The frequency range mentioned is typical of what a PV inverter manufacture will specify. In a traditional grid infrastructure the frequency is quite stable. The PLL module can work for larger range of frequency if you use adaptive notch filters and use update the center frequency adaptively.  If you experiment you will find the PLL locks for  54 to 66 Hz as well, but you may get more error in your phase lock.

I'm trying to generate a sine wave on CCS v4.0 using C28335 as my target. The C code is below :

# include <math.h>

int x;
float k[360];

#define PI 3.1415926

void main(void)
{
        while(1)
           {

              for(x=0; x<360; x++)
                {

                      k[x] = (float)sin(x*(2*PI)/360);

              }

       }
}

but the numbers I get after execution seem to me like random numbers. Sometimes I get the right values till, say, 120 and then all values are set to 0. And rarely I get all the values right! 

My stack size is 400.

Could anyone tell what the problem is?

Thank you.

To clarify, I'm using the Peripheral Explorer's Kit (TMDSPREX28335)

Hi,

Sorry for the noob question, but I have limited experience with TI MCUs. I recently ordered the COMBOSOLAR sample pack and it includes a TMS320F2808.

I'm use to working with PICs(PIC24 and dsPICs) and the MSP430 Launchpad. Microchip sells the Pickit series of programmers, I presume TI has something similar but I can't seem to find it. The closest thing I can find is the ControlStick would this be the best way to get started?

I also realize that this MCU is a step above the 16-bit micros I'm used to, so any resources you could point me to would be very helpful.

Thank you in advanced for your attention.

Best Regards,

Jorge Garcia

Sina,

I've duplicated the issue and I'm working on a resolution.  In the mean time, have you looked at the signal generation library?  It can generate signal like this much more efficiently than what is done in this snippet.

Take a look in:

C:\TI\controlSUITE\libs\dsp\SGEN\v101

Regards,

Trey

Hi,

Sorry for the NOOB question, but I have limited experience with TI MCUs. I recently ordered the COMBOSOLAR sample pack and it includes a TMS320F2808.

I'm use to working with PICs(PIC24 and dsPICs) and the MSP430 Launchpad. Microchip sells the Pickit series of programmers, I presume TI has something similar but I can't seem to find it. The closest thing I can find it the ControlStick would this be the best way to get started?

I also realize that this MCU is a step above the 16-bit micros I'm use to so any resources you could point me to would be very helpful.

Thank you in advanced for your attention.

Best Regards,

Jorge Garcia

This might be a double post, if it is I apologize please feel free to delete one of the two copies. Thank you again

Sina,

After some more investigation, I believe the watchdog is firing midway through your execution and resetting the device.  If you haven't already, download controlSUITE.

Once installed, go here:

C:\TI\controlSUITE\device_support\c2834x\v112\DSP2834x_examples_ccsv4

There you will find tons of examples for this device.  Specifically look at the FPU_Software example (you can import it by selecting file, import, import CCS projects).  I was able to get your code to run, by pasting it into this example.  Give this a shot, code was as follows:

#include "DSP28x_Project.h"     // Device Headerfile and Examples Include File
#include <math.h>

float y1, y2;
float m1, m2;
float x1, x2;
float b1, b2;

int x;
float k[360];

volatile unsigned long y;

#define PI 3.1415926

void main(void)
{

// Step 1. Initialize System Control:
// PLL, WatchDog, enable Peripheral Clocks
// This example function is found in the DSP2834x_SysCtrl.c file.
   InitSysCtrl();

// Step 2. Initalize GPIO:
// This example function is found in the DSP2834x_Gpio.c file and
// illustrates how to set the GPIO to it's default state.
// InitGpio();  // Skipped for this example


// Step 3. Clear all interrupts and initialize PIE vector table:
// Disable CPU interrupts
   DINT;

// Initialize the PIE control registers to their default state.
// The default state is all PIE interrupts disabled and flags
// are cleared.
// This function is found in the DSP2834x_PieCtrl.c file.
   InitPieCtrl();

// Disable CPU interrupts and clear all CPU interrupt flags:
   IER = 0x0000;
   IFR = 0x0000;

// Initialize the PIE vector table with pointers to the shell Interrupt
// Service Routines (ISR).
// This will populate the entire table, even if the interrupt
// is not used in this example.  This is useful for debug purposes.
// The shell ISR routines are found in DSP2834x_DefaultIsr.c.
// This function is found in DSP2834x_PieVect.c.
   InitPieVectTable();

// Interrupts that are used in this example are re-mapped to
// ISR functions found within this file.


// Step 5. User specific code, enable interrupts:

//
// Calculate two y=mx+b equations.

   y1 = 0;
   y2 = 0;
   m1 = .5;
   m2 = .6;
   x1 = 3.4;
   x2 = 7.3;
   b1 = 4.2;
   b2 = 8.9;

   y1 = m1*x1 + b1;
   y2 = m2*x2 + b2;

   for(x=0; x < 360 ; x++)
   {
           k[x] = (float)sin(x*(2*PI)/360);
   }


   ESTOP0;  // This is a software breakpoint
}


Regards,
Trey

Hello,

I have a question regarding the ADC in Piccolo 28069 devices. If we configure the ACQPS register to less than 6, the ADC still gives valid results and the effective sampling rate is much faster. We take it down to ACQPS=1 and still works (only at 0 stops working). The datasheet says that any value below 6 is invalid.

What does it mean by invalid? is it that it doesn't guarantee the ADC specs? does the conversion actually get much worse with values lower than 6?

We also noticed that the ADC still works with an ADC clock of 80MHz (40MHz seems to be the maximum), is this a similar situation of not guaranteed specs?

I'm wondering why the peripheral takes this "invalid" values and does not block them.

My other question regarding the ADC is: does the ADC guarantee accuracy specs even in OVERLAP mode (NONOVERLAP bit set to 0). I've read that the NONOVERLAP mode is used to give better INL and DNL.

I would greatly appreciate if all my questions are answered! I'm counting on the specified accuracy and speed to make my control loop possible and it would be too bad if I find surprises in the middle of the development. 

Thanks,

Max 

Max,

I'm no ADC expert, but I know how the docs are written and if you use the device outside of how we tell you to use it the specs are NOT guaranteed.  We do not characterize the devices outside of the ranges specified so behavior is questionable.  The answer to both the ACQPS and ADC Clock questions are we cannot guarantee any type of performance in these ranges. 

There are tons of registers on the device that will take invalid values.  Its your responsibility as the programmer to program correct values into the registers.  This is why we supply reference manuals and datasheets.

I can't comment on overlap vs. no overlap, but your statement that no over lap gives better INL and DNL does seem reasonable.  I'll get an analog expert to take a look at your questions as well and see if they have anything to add.

Regards,
Trey

Trey,

Thank you so much, I'll download it and will try to try it out the way you did it.

I found the UARTprintf() function will not print 16 bit integers.  For example,

Code:

unsigned int a = 1234;
UARTprintf("a = %u\r\n",a);

Result

a = 80872522

Jut,

Could you give me more information about the problem?  What device are you running on?  Where did the UARTPrintf function come from?

Trey

Trey,

I did as you said but when I try to build my project I get this error :

undefined first referenced
library "libc.a"
symbol in file
--------- ----------------
_InitPieCtrl ./Lab3_3_1.obj
_InitPieVectTable ./Lab3_3_1.obj
_InitSysCtrl ./Lab3_3_1.obj
code_start

error: unresolved symbols remain
warning: entry-point symbol "code_start" undefined
error: errors encountered during linking; "Example_2834xFPU_software.out" not
built

>> Compilation failure
C:\Program Files (x86)\Texas Instruments\ccsv4\utils\gmake\gmake: *** [Example_2834xFPU_software.out] Error 1
C:\Program Files (x86)\Texas Instruments\ccsv4\utils\gmake\gmake: Target `all' not remade because of errors.
Build complete for project Example_2834xFPU_software

Hi Trey,

I'm running on the F28069 usb dev board.  

The printf function comes from ti's controlsuite library, found here:  C:\ti\controlSUITE\device_support\f28m35x\v140\MWare\utils\uartstdio.h

Note that I can successfully use UARTprintf() with longs and strings.

Jut,

This is probably an artifact left over from porting this library.  This originally came from the Stellarisware package and was intented to run on a M3.  I'll file a bug and try to get this fixed for the next release.

Trey

Hi Manish,

By adaptive notch filter,  you mean I need to update the coefficients of the filter after each Sine wave period (60Hz) based on the real-time AC input (grid) ?

I saw in one of your postings , you mentioned designing the Notch filter in Matlab using

[B_notch,A_notch]=butter(1,[110*2/Fs 130*2/Fs],'stop')

if the center frequency is 60Hz.

So, if the center frequency now is 55Hz, then the Matlab formula should be

[B_notch,A_notch]=butter(1,[100*2/Fs 120*2/Fs],'stop')

right?

and,

Whay is the stop band 2Wo -+ 10, not 2Wo - + 5 ? How do you decide that band ?

Trey,

okay the issue is fixed, I just changed the target example to 283X as my target is 28335.

Thank you for your help.

Regards.

Sina

Trey,

Thanks for responding to my post, but unfortunately you didn't answer to any of my questions. I was already assuming everything you wrote.

I would really appreciate if you could forward my questions to the expert. I can tell you that I have seen non-responded posts asking about the "weird" behavior of the ADC with changes in the ACQPS (within the allowed limits), and I have also experienced it.

Regarding the ADC specs, I find hard to understand why with an INL of +/-4LSB and an offset error of +/-4LSB (after offset calibration) you end up with a gain error of +/- 40LSB (with external reference). Could you please forward also that question? Again, I have seen older posts regarding this issue with no reasonable answer.

I am using 28035 devices in production units and they are much better than +/-40LSB before any calibration (only the offset correction routine). I suggest that adding to the datasheet some simple plots of when the error gets that high would help a lot to take advantage of the device.

Thanks again,

Max

Max- as Trey implied, the best way to avoid surprises is to use the device within datasheet specs.  Even though you may find a device that has good performance when operating outside these conditions and specs, there is no guarantee that all devices will perform the same or that the particular device will perform well across all operating conditions.

With regards to linearity performance in overlap mode vs. non-overlap mode, some devices could show better linearity performance in non-overlap but once again, nothing can be guaranteed beyond the datasheet limit.

Joe/Trey,

Is there any place where I can find the explanation of how with an INL of 4LSB you get to 40LSB of gain error with external reference?

With my question about why the ADC works with ACQPS values lower than 6 I'm trying to find out how the ADC really works inside. Looks like reducing the sampling window affects the ADC conversion time, which is not what the explanation in the datasheet says. I take the ACQPS to 1 and the conversion time per channel is 7 cycles, the converted value looks identical. I see that the accuracy cannot be guaranteed but how can a SAR type ADC generate a conversion in less cycles?

I am not trying to get from you a guaranteed spec of the ADC working outside the recommended conditions, but I'm just trying to make sense of the real limitations of the ADC and how I can optimize it. If I used the spec of +/-40LSB error with external reference, I couldn't use this ADC because it would be the worse ADC ever...

Thanks,

Max

Max,

Even if the INL and offset of an ADC are zero, there can still be gain error; they are unrelated specifications that, when combined, describe the error characteristics of the ADC.  Even with a perfect external reference, ADCs will have gain error because the external signal must cross into the device and be used by the internal circuitry.

The time for the converter to process a voltage in this ADC is always 13 cycles. In no-overlap mode, the total time is roughly converter time + acquisition time. This allows an effective time between samples of no less than 13 + 7 = 20 cycles.  In overlap mode 7 cycles of the acquisition window are overlapped with the conversion time, allowing an effective time between samples as low as 13 cycles.  The ADC will NOT reliably work with a less than 7 cycles of acquisition window both because the digital wrapper is not designed to align the timings this way and because the internal sample cap will not have enough time to charge.

Note that the ADC is not a SAR architecture.  Its internal construction uses elements of both a SAR ADC and a pipelined ADC.  

How are you measuring the time it takes to sample(conversion time per channel is "7 cycles")?  Are you feeding in a periodic signal of known frequency, sampling it into a buffer, then calculating the sample time by measuring the digitized period?

How are you determining that ACQPS setting < 6 is producing good results?  What kind of signal source are you using?  How many samples are you taking? Are you sure the results registers are updating?

The gain spec is admittedly not great, but some applications are quite tolerant of gain error.  

By adaptive notch filter,  you mean I need to update the coefficients of the filter after each Sine wave period (60Hz) based on the real-time AC input (grid) ?

I saw in one of your postings , you mentioned designing the Notch filter in Matlab using

[B_notch,A_notch]=butter(1,[110*2/Fs 130*2/Fs],'stop')

if the center frequency is 60Hz.

So, if the center frequency now is 55Hz, then the Matlab formula should be

[B_notch,A_notch]=butter(1,[100*2/Fs 120*2/Fs],'stop')

right?

and,

Whay is the stop band 2Wo -+ 10, not 2Wo - + 5 ? How do you decide that band ?

Yes, adaptive notch is exactly that, however it may be an overkill for a simple grid connected systems.

I'll recommend you try the PLL as is for the desired frequency range. Honestly you already have two frequency coefficients in the code one for 50Hz and other for 60Hz those should cover you for the most part. You can try different values there is no substitution for experimentation :) these worked good for the application.

All:

I posted a question regarding Crystal ESR - is there an expert onhand that can answer?

Reposted today... original chain is here:

http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/p/207212/741599.aspx#741599

Hi Todd,

I'll see if I can get some to tackle this question.

Regards,

Trey

I know that I am outside of the posting window, but perhaps I might catch someone.  I am new to the TI line of MCU's coming from PIC18s.  I had been considering dsPIC33 series when I came across the C2000 processors.  My question is this, in the dsPIC there is a capture function that allows one to easily measure the length of a pulse (between a rise and fall of the signal).  For what I am doing (I am reading eight servo inputs which are on a 1-2 micro second duration and about a 25 micro second frame rate) the pic had enough inputs to use this capture function.  When looking at the 28069 there are only 3 capture inputs and they are multiplexed to the encoder input as well as the usb, which did not leave me with any real pins to be able to use this function.  I was looking to implement this via an external interrupt that would start and stop a timer when I came across a statement that there is an input counter that can be started and stopped.  I have not been able to read too deep on this counter, but does this happen to have a prescaler, and if so, is there a code example of how to use this timer/counter in conjunction to the interrupt.  I think that the manual mentioned that there were on the order of 13-15 of these counters available.

Adam

For someone switching from a dsPic to a C2000, there will always be someone on the forums to help out!  :-)

I did some looking around in the technical reference manual and there are in fact counters associated with the external interrupt, but remember there are only 3 external interrupts.  The counter is free running and is reset whenever the corresponding external interrupt fires.  There is no pre-scalar for this counter register BUT if we take into account the SYSCLOCK rate that it can be clocked at (80MHz) and the fact that it is a 16 bit counter we'll find that the counter will take 819uS to roll over.  Check out page 183 of the technical reference manual.

Hope this helps!

Trey

Devin,

Thanks for the response. Here are my comments regarding the 2 parallel conversations that we are having:

1) Most of the ADC datasheets that I have used describe where the error comes from, so you can know what you have to do to minimize its impact in your application (2-point calibration, N-point calibration, external reference, using one of the ADC channels to sample an accurate reference, etc). Jumping from 4LSBs of INL to 40 or 60LSBs without any explanation of the reason is what I find "interesting" about this datasheet.

One thing that would help me is if what the datasheet specifies as gain error is something that can be calibrated with a 2 point calibration (I assume that a gain is a proportional factor) and the only error left would be INL and a temperature coefficient of 20ppm with external reference. With temperature "coefficient" I assume that the temperature affects only the gain and not the offset.

I also assume that the offset can change only +/-4LSB over the whole temperature range. It would be interesting to have a temperature "drift" for the offset,  so I can now the worst case change for my particular operating range and not for a -40 to 125C temperature range.

2) Regarding the ADC timing: I am sampling a 50kHz periodic signal at 500kHz and save the 10 samples in memory with the DMA. This periodic signal is the output of a PWM passed through a low pass filter, so the ADC sampling is perfectly synchronized with the signal. I plot the samples with the graph tool of CCS5.

I can see that I'm acquiring the same waveform that I get in an oscilloscope. If I change the ACQPS value within the "allowed" limits (>6) there is a small but noticeable variation in the sampled values, which is the first thing that I find interesting about this ADC. I have experienced this issue in the past: The value of ACQPS changes the result of of the conversion even though the signal is not changing significantly during the duration of the sampling window.

But the most interesting thing that I see is that if I bring ACQPS below 6, down to 2, I still see the same behaviour. Valid samples, identical waveform, only small variations in the exact values of the samples.

I know the time it takes for the ADC to sample and convert because I'm converting several channels and I see the little glitch in the ADC inputs when the S&H samples the signal.

It is worth to note that there is no external noise affecting my setup because the acquired waveform looks identical every time, the graph looks frozen even though it's being updated continuously.

My conclusions from this test are:

1) The ADC can sample and convert in 9 ADC clocks (ACQPS=2, with overlap mode), I assume that 3 clocks are for sampling and 6 are for ADC conversion.

2) The effect of changing ACQPS below 6 is as bad as (or as small as) changing it to values over 6 (7, 8, 9). The individual samples change few LSBs and the acquired waveform is almost identical.

Does this information help you to find an explanation to my questions?

My other pending question is if the overlap mode affects the INL (or the error) of the conversions.

Regards,

Max

Max,

I really don't follow your comment about going from 4 to 40 LSBs.  The INL has a max specification of 4LSBs over VTP and is guaranteed by test.  

The error for the ADC is broken down as follows: 

+/- 4 LSB of INL, which can not be corrected by any type of calibration

Up to +/- 40 LSB of gain error (external reference) across VTP. This gain error has a temp co of approximately 20ppm.  You should be able to calibrate this out with 1 point calibration.  The extent you can calibrate this is limited by how accurately you can measure the gain error, which is limited by the INL, offset error, and channel to channel gain error, all of which are spec'ed in the datasheet. I would recommend an external high precision 2.5V reference IC to do this if desired. 

Up to +/-20 LSB of offset error across VTP.  We provide a built in method to do a self-calibration, which, when done periodically, will get you down to +/-4 LSBs. 

All of the ADC DC error specs (INL, gain error, and offset) will be affected by temperature.  We only give a temp co for gain. All the specs are worst case over the full temperature range.

Overlap mode will generally make the INL better (as will lower ADC clock), but we do not have a spec tighter than +/- 4 for this.  

It is invariably true by design that the ADC will take 13 cycles to convert a voltage to a digital code. The ADC also must sample the voltage, which takes additional time.  In overlap mode, up to 7 of these sampling cycles are overlapped with the voltage conversion time to hide the latency.  With ACQPS = 6, all 7 sampling cycles are overlapped with the conversion time. This gives a time between samples of 13 + 0 = 13 cycles. With ACQPS = 23, 7 of the 24 cycles are overlapped with the conversion.  This means the total cycles between samples will be 13 + 17 = 30.  Even if you set ACQPS less than 6, the converter must still take 13 cycles and the time between samples will be at best 13 cycles.

Note that changing the ACQPS within the valid range will change the timings between when the ADC sampling and converting, especially in overlap mode. This will give some small variation in observed samples.

I am not sure why your setup is leading you to believe that the ADC can convert in less than 13 cycles, but I assure you that it can not.  I would recommend sampling an input sine wave continuously at full speed for at least a few periods, then looking at how many points the sine wave is broken into.  

Devin,

Thanks for the answer.

There are a couple of things that may be confusing me, could you please clarify them?

1) The specification of "gain error" with a unit of LSB seems to be conceptually wrong. A gain should have no units and should be specified in % or similar unitless way because it is not an absolute value by definition. What's your opinion about this?

2) I read this post: http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/t/36283.aspx

And the TI employee gave the best explanation that I have seen so far about the origin of the +/-40LSB. What I understand from YOUR text is that the 40LSB of gain and 20LSB of offset are "unpredictable" or "system-level" and I should add the temperature variation on top of it. This is not what Matthew wrote. Please correct me if I'm wrong.

In my previous products I ran the offset calibration only one time and it worked fine. Running a that periodic calibration routine to remove "system-level" dependencies sounds interesting. I don't know if periodically is 1 minute, 1 second, 1 day or what. In any event, I cannot stop for several microseconds what the DSC is doing to run a calibration because it is obviously executing real-time tasks.

3) "Overlap mode will generally make the INL better (as will lower ADC clock), but we do not have a spec tighter than +/- 4 for this.  "

I do not understand why the overlap mode will lower the ADC clock. All that I need to know is that the INL or gain error does not get worse with overlap mode.

4) "I would recommend an external high precision 2.5V reference IC to do this if desired. "

If I need a "decent" gain and offset drift (less than 40LSB and 20LSB), do you recommend me to continuously sample the 2.5V reference and 0V internal connection to calibrate gain an offset of the ADC? Have you seen that doing this allows eliminating those potential 60LSB of error and only live with the INL and channel to channel error?

5) "Note that changing the ACQPS within the valid range will change the timings between when the ADC sampling and converting, especially in overlap mode. This will give some small variation in observed samples."

I don't understand why timing would change the acquisition of a signal that is almost steady during the sampling window.

6) For now let's not continue the conversation about the ADC converting in less than 13 cycles. I'm sure that the time between samples is less than 13 cycles because I'm measuring it with the oscilloscope, and  I'm almost sure that the 10 samples per period are valid, but I may be missing something. In any case, I don't want to take the risk of using the ADC outside the specified limits so I don't need to clarify this issue.

Regards,

Max

Max,

1) Gain error is usually spec'ed in LSBs for an ADC.  This is the most common way of defining it, but a percentage of FSR could also convey the same information.  LSBs are convenient because other ADC error specs are also in LSBs.  This document gives a pretty good overview of the standard technical definition of ADC terms, including gain error:

http://www.national.com/assets/en/other/definition_of_terms.pdf

2) As previously stated, ALL datasheet min/max parameters are over the full operating range, including temperature.  You should not add a temp coefficient on top of these specs.  However, please note that temperature is not the only condition that leads to the min/max spec, process and voltage also come into play.

3) No-overlap mode will slightly improve INL.  Lowering the ADC clock will slightly improve INL.  I did not mean to imply that no-overlap mode will lower the ADC clock. 

4) The documentation for the device provides a spec of +/-4 LSB offset error when using the built in connection to VREFLO to periodically calibrate out offset error. A spec of +/-4 is the limit because channel-to-channel offset variation limits how accurately you can measure the offset.  Gain error and INL do not affect measuring the offset. 

The short answer for gain error is no, you will not be able to calibrate it completely. The calibration measurement depends on the accuracy of the external reference, gain error, INL, offset error, and channel-to-channel gain variation.  These limit how accurately you can measure the gain and calibrate out the error.  After calibration, the gain will have residual error AND you will still have the errors that originally limited your measurement.  I would estimate that you could probably get a gain error of around +/-20 LSB, but I do not have a spec in the datasheet, an application note, or any experimental data to support this. 

5) I am referring to how the internal architecture pipelines the conversion.  There is no reason this would happen on an idealized ADC.

Hello Manish,

I have been trying to use the SPLL module developed by you to track the frequency changes. While trying to use this method, the variable spll1.wo which is the instantaneous grid frequency does not change. 

The code snippet  used:

SPLL_1ph_init(60, _IQ21(0.000025), &spll_phA);

spll_phA.AC_input = V_phA;

SPLL_1ph_run(&spll_phA);

wout = spll_phA.wo;

The range of the input ac is from -1.0 to 1.0. From the TI docs, the wo term is integrated to obtain the corresponding the theta.  Hence, should'nt the omege change with the change in frequency of the input. My sampling frequency is 40000Hz. 

Kindly let me know where is the issue with the program, as there is no compilation error generated. 

Nikhil,

The wo will change, if you look at the code the PLL locking mechanism depends on this

spll_obj->wo=spll_obj->wn+spll_obj->ylf[0];

You will need another low pass filter at spll_obj->wo to actually get a stable value for the ferquency

Alternatively a ZCD detect on voltage sensing can be connected to the CAP for accurate frequency measurements, this can further be used to fine tune the spll_obj->wn value for better accuracy.

Additionally the PLL module is designed for 20Khz operation you will need to change the coefficients etc for any other frequency of operation, i'll suggets running the PLL every alternate cycle to quickly verify the operation