For accomplish this resolution arduino has to use the Timer1, that has the 16bit resolution. Arduino clock runs at 16MHz

Does that tell me the PWM output frequency?

 

If 16 bit PWM takes 16 Mhz clk, and its run at its max period then
f = 16 Mhz / 16 bits = 244 Hz

Problem with using two dacs is it will no longer be monotonic.

https://electronics.stackexchange.c...ts-dacs-together-to-create-a-16-bit-dac-one-b

https://e2e.ti.com/support/data-con...Summing-Two-16-Bit-DACs-for-24-bit-Resolution


Regards, Dana.

 

If 16 bit PWM takes 16 Mhz clk, and its run at its max period then
f = 16 Mhz / 16 bits = 244 Hz

Problem with using two dacs is it will no longer be monotonic.

I'm not suggesting using two DACs in interleaved fashion or any other method that will produce non-monotonicity in a single ramp. One generates the 10 mV steps - that's all it ever does. The other generates the offset for the ramp and its output remains fixed for the duration of the ramp. Quad 12 bit DACs don't cost a lot and two sections could be used for fine and coarse offset adjust. Of course the voltage reference is critical in all of this, as are components with good initial tolerance and low drift with time and temperature.

The other important consideration is that of measurement of the response to the ramp. It is likely impossible to justify more than 12 bits of anything if the Arduino ADC is to be used.

The reality is that a dual 16 bit DAC of suitable performance might as well be free compared with the cost of doing development, unless a lot of units are to be made. There are 14 bit DAC available that would be sufficient for 10 mV steps over a 80 V span, but I doubt if the savings relative to a 16 bit DAC would be worthwhile unless pennies count.

 

Well, I've been studding the linearity of the arduino PWM with 16bit and set frequency of 5kHz to good response of the filter.


it's, near perfect as you can see XD.

Now that I have the input of the dac established with arduino+ filter+following opamp.
About using two DACs, it can be a good solution for selection of the range to apply the ramp, what type of DAC do you recommend to use? I'm really newbie (as you all see) using DACs. I've been searching info about and I can't find one with more than 40V, and maybe is better one system with one DAC for the aprox 30V ramps and more simpler supply to shift this ramp in the correct range.

PD: what about this one, can it serve for what i want? http://www.farnell.com/datasheets/2...MIyt2qrJ7l3gIVRoXVCh0qdgmxEAAYASAAEgKudfD_BwE

 

Update: what about putting one of these: https://www.digikey.es/product-deta...2644CMS-L12-PBF/LTC2644CMS-L12-PBF-ND/4964730

with an op amp after?

 

Looks good, in low volumes makes sense. Although G error is 1.6%
total, which is ~ 7 bits absolute accurate, not including Vref error.

If you are cost conscious for a volume design then a PSOC 4 or other
UP can do this < $ 2, and have much more HW capability for other
tasks.

Regards, Dana.

 

After doing a little more searching and finding several 16 bit serial input DACs that are quire inexpensive, that is what I would use.

Although the PWM to analog converter will work, if you use the 16 bit PWM counter in the Ardunio and can't configure it to "shorten" it to 12 bits, your update time will be about 4 milliseconds. You would need a mechanism to tell the software that an update was complete, such as an interrupt when the PWM counter completed a cycle. This isn't likely difficult, but it may add timing uncertainty that you might not want.

If you use a true DAC, you know exactly when the update occurs without waiting. A true DAC also allows some improvement in flexibility by making the analog portion less dependent on the specific microcontroller and the way it operates. Because the integral non-linearity of many 16 bit DACs can be moderately high, I would suggest using a good 16 bit DAC but treating it as if it were 14 bits. After amplification, this would yield a total span of 82 volts with 5 mV per step resolution, which is better than the requirement.

Care would be required in this sort of test system to be sure that the output was properly configured before the device being tested was connected so that voltage outside of the allow range for any particular device under test was not exceeded.

Analog Devices, Texas Instruments and Maxim all make 16 bit DACs that should be suitable. Various serial input types are available. Some can be had in different grades where the better grade offers improved integral non-linearity for a somewhat higher cost.

PWM non-linearity can be extremely good if the design is done with care. The problem is that the settling time with conventional filtering will be VERY long unless the counter runs at very high frequency. A 16 bit counter would require a clock frequency of about 64 MHz for an output frequency of 1 kHz.

 

Okay, I'm taking note of all of your comments, I think with all commented here I can do it well in my project! I will update you with the progress. Very thank you all!

 

Most PWMs can be configured to HW update at end of cycle/period. This makes their
update synch to main PWM clk. So only jitter is main PWM clk jitter. Normally
quite low for an application like this.

Settling time normally expressed as a FS (Full Scale) jump in value. But
if you are doing a ramp settling time is time to settle 1 LSB change in PWM.


Decision rides on your desire for absolute accuracy vs relative accuracy. The
DAC solution I think more costly but easy to implement. Whereas PWM means
either precision low noise Vref (if absolute accuracy) on UP power pin, or use
external MOSFET switches tied to a Vref to eliminate UP internal generated
power supply rail noise. PWM << cost than DAC. PWM also inherently a noisier
solution, more demanding on filtering.

Trade-offs, always trade-offs....


Regards, Dana.

 

Sure, PWMs are normally configurable to free run - and that is the problem with using the PWM to analog converter. The converter updates on the rising edge of the PWM signal, so the time interval from rising edge to rising edge must be consistent, which is no problem with a free-running PWM. What is a problem is that the the processor, without added "something" has no "knowledge" of when the rising edge occurs and in consequence has no knowledge of when the output of the converter has been updated. An interrupt at the end of the count is probably easy to configure, but it means that the uncertainty in when that happens is essentially the full period of the counter, which may be OK or not. It does mean you likely have to structure the program around that issue. With a real DAC, you simply set the DAC and then know exactly when you can read the response from the system under test.

Fussing about the cost of the converter in this application is just a complete waste of energy. If I were a paid consultant on this project, I would already have billed more money for looking at datasheets than it would cost for converters to build several systems. I've designed and built all sorts of custom instrumentation. A part that costs 25 dollars or pounds or euros might as well be regarded as being free in the overall scheme if there is just one per unit and a small number of units to be built. Obsessive counting of pennies is for the producers of high-volume consumer products.

 

Yes PWMs and DACs both share latency to update, PWM more so because
of LPF. The PWM - Interrupt uncertainty problem, in some processors, can be
synced to a clock to alleviate that issue, but that also adds latency.

I can't speak to the budget considerations of the poster. You are certainly correct
about using off the shelf DAC, the additional part fast fix for a one off design, even
if one considers the extra proto time to handle and learn another part and to write the
attendant software needed. But that's small potatoes I think.

You raised an interesting point about PWM running continuously. There are PWMs
out there that can be operated in single shot mode. I never thought about that approach
for a DAC.......something to think about. DAC on demand so's to speak. Minimize
Pdiss not needing a continuously running PWM.......

Regards, Dana.