65 posts / 0 new

## Pages

I some how got confused between average mode control and real time . What I always did in my digital control course is is sensing the output and subtract the feedback(output) from the set point and then the error signal is fed to a controller which gives out a control action to the plant. What I can not define is the averge mode control

Last Edited: Mon. Oct 30, 2017 - 05:07 PM

Miramiro wrote:

Do you mean by real time control ,changing the controller according to the operating point? and If I try implementing this with AVR , things will not work because its over the capabilities of the AVR

At the end of the day, if you are sampling at 13us intervals, then all your calculations have to take place within those 13us. At 16MHz that means you have 208 (16x13) instructions cycles to play with.

You've written some code back in post #27, run that in the simulator and see how long each iteration of loop() takes.

'This forum helps those who help themselves.'

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

I am saying that real-time, at the scale of even a few microseconds, is not possible because the ADC takes much longer than that for a reading. For example, your original goal in message #1 was 13uS decision interval for switching. Since the fastest ADC conversion rate for full 10 bit resolution is 65uS, you CANNOT make a new decision every 13us.

There are many ways to solve this problem. I listed one, above (average mode). Here are some more:

1. Shift to a micro with a much faster ADC. This might include one of the XMega devices. This would also get you faster processing speed.

2. Use an external ADC with a faster clock rate. You would still have the problem of moving the data from the ADC to micro, either in parallel (takes lots of pins) or serially (takes longer time).

3. Use a technique that does not use the ADC. A comparator comes to mind.

Average mode is easy. Negative feedback will settle it at the desired operating point. Simply measure the AVERAGE output voltage (ripple significantly reduced or removed). Compare the observed value to the desired value. If the measured value is too low, increase the duty cycle. If the measured value is too high, decrease the duty cycle. The only real challenge is the algorithm you use to modify the duty cycle. One scheme suggested above is that if the duty cycle is too low, increase it by one clock unit and take a new measurement. Ditto, if duty cycle is too high, decrement it and take a new measurement.

Hope this helps,

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Oct 30, 2017 - 06:21 PM

ka7ehk wrote:

I am saying that real-time, at the scale of even a few microseconds, is not possible because the ADC takes much longer than that for a reading. For example, your original goal in message #1 was 13uS decision interval for switching. Since the fastest ADC conversion rate for full 10 bit resolution is 65uS, you CANNOT make a new decision every 13us.

Jim

It is the first time I know that the adc conversion take that long ..When I was writing the code I opened the datasheet of ATMGEA 2560 and it Says that in "auto triggering" mode the conversion takes 13 ADC clock cycles (my adc clock cycle is 1MHZ) so this means the ADC conversion should talk 13usec only.. how did the time 65 usec comes from?

please check the 2 pictures attached .

We (several of us) have been trying to tell you this, almost from the start of the thread! Let me emphasize the information you just included

By default, the successive approximation circuitry requires an input clock frequency between 50KHz and 200KHz. If a lower resolution than 10 bits is needed, the input clock frequency to the ADC can be as high as 1000KHz to get a higher sample rate.

While it does not say explicitly here, the clock rate must be 50KHz to 200KHz FOR 10 BITS RESOLUTION. You no longer have 10 bits when the clock is faster than 200KHz. 1000KHz should get you something around 8 bits.

65us comes from 15 clock cycles with a clock of 200KHz.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Oct 30, 2017 - 08:38 PM

first you are correct about the 13us when you only need 8 bit.

We need go a step up and look what you want. So here are some questions :

1 why do you need so fast a sample rate ?

2 do you really need to react on that fast changes in load (and there for voltage), if yes I would say that there are a HW problem with the output filter (ripple cap to small or internal resistor to big).

3 the HW should be made so no changes (steady state) there should be about no CPU power needed, from some of the comments it sounds like you want an update every 13us (back to question 1)

4 can we see an idea about a diagram?

or the input voltage for your ADC can see it's own switching signal, in that case you need to filter the input (in HW).

Last Edited: Mon. Oct 30, 2017 - 09:03 PM

He wants to control the upper and lower trip points for the switcher in real time. That is, he wants to make a decision every 13us whether or not to change the state of the MOSFET switch. That is why he needs it fast.

Some of us have been promoting the idea of using a timer-based PWM and simply controlling the timer compare value once each PWM cycle. This is the "average mode" I have been talking about, but the OP seems to be fixated on real-time. I argue that An AVR (Mega or Tiny) with its fairly slow ADC and slower MCU clock rate is simply not the tool to do this in real time. Until just now, the OP has seemed not to believe the assertions that the ADC is "so slow".

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

then I have to add to #58

why do you want to switch that slow (1/13us)? you will normally be better of switching way faster, and then (partly with HW filters), make a way slower control loop.

I mean by "real time" that the control algorithm actively decides when to turn the switch on, and when to turn it of. This appears to be what you started out, attempting to do. With the speeds that you are seeking, it simply does not match the capabilities of an AVR, Mega or Tiny. You MIGHT be able to do it with an XMega that can do an ADC conversion in something around 1us and has a clock rate that is probably sufficient to realize your control strategy.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

sparrow2 wrote:

first you are correct about the 13us when you only need 8 bit.

getting a resolution of 8 bits , does that mean that the lowest 2 significant bits will be unreliable , right?

I have been searching for a way to a get this  and I found some people trying to do so in their projects.

the adc is a charge balancing converter, so if you clock them too fast, the charge doesn't have enough time to settle, so you get reduced resolution.

The datasheet is pretty clear on the implication of high speed clocking, so why are we hanging on to this? Currently the adc is the least of your problems.

That dependse (look at the data sheet).

Either you just read 8 bit(faster), or read 10 bit , but expect more noise than when clocked "correct".
For a signal that is very steady (which I hope yours are) you get a relatively good reading.

But remember that if you change the mux for the ADC it will get slower, and fast readings will have bigger errors.

Miramiro wrote:
it works as buck when Vin > 5 volts and works as boost when the Vin < 5 volt

You should have hysterisis for that. Or it will oscillate between buck and boost mode.
Since dc supply always has pretty big cap at input and output (uF) so your insist of speed checking is not really necessary I think.
Sometimes being slow is better than too fast.
.
MG

I don't know why I'm still doing this hobby

Last Edited: Wed. Nov 1, 2017 - 06:58 AM