Reconstruction Filter

[Ttelmah]

You won't get to 3.4MHz with the PIC. Read the data sheet. Look at how the I2C is clocked. You can then work out the maximum it can generate.

I thought you had launched a separate thread using an SPI DAC?. This supports much faster speeds. Even better, no start and stop needed.
With I2C, BRG divisors of 0, 1 & 2 are not legal.
So the fastest supported is:
Fosc/16
With SPI, the fastest supported is Fosc/4. Then remove the start and stop transactions, and you have a speed at least perhaps 6* faster.

[viki2000]

Yes, I was thinking to test in parallel and see the limit of I2C approach 1st.
You say:

[Ttelmah]

As that would be over the maximum supported by the slave chip, that would be rather silly. However you also need the active pull-ups as already mentioned. You can get a bit above specifications without these, but as you get faster they become more and more essential.
Honestly pushing I2C this fast is asking for even more problems.
SPI is designed for higher speeds (active transceivers in both directions).

[viki2000]

But I did not intended to drive it at 4MHz. I just wanted to show that if the PIC can 4MHz according with your proposal, then for sure can also 3.4MHz, the max. of MCP4725.
Now, if I understand right, when comes to higher speeds than 400 KHz of I2C, as these high speeds 3.4 Mbit/s, then your recommendation is drop it, forget it, close the case, because it makes only trouble and I should focus on SPI. Is that right?

[Ttelmah]

On I2C, there are four different speed standards.
Standard mode - 100kb/s max
Fast mode - 400kb/sec max
Fast mode+ - 1Mb/sec max
High speed mode - 3.4Mb/sec max.

HS mode requires active termination. So the terminator actually switches to give a faster edge. Also HS mode changes the way that clock stretching is handled. The PIC can drive Fast mode+, but does not as standard support HS mode (though it's drivers can actually generate the higher current this involves, and it is possible to drive HS with a PIC, but it requires custom PIC drivers, and a lot of luck).
Now all the faster modes will become relatively hard to handle.

Generally in electronics, one of the things to learn is that for reliability always work 'inside' specs, don't push up towards limits if you want reliability.

Now, honestly you are making a lot of work for yourself. If I wanted a half wave like this, I'd actually generate a full wave, and then rectify it.

Why?.

The reason is the harmonics. It is far easier to synthesise a really clean sinewave, since you can then just use a filter to reject the quantisation noise.

Then I'd not fiddle around with a PIC and DAC. Instead use a chip designed to do the job. There are sine synthesiser chips on the market that are able to do a much better job.

[temtronic]

Maybe it's just me but I keep looking at this post and think it's like using a sledgehammer to hit a tack. Way overkill for the job, too much time spent when you consider what Mains power really looks like. Or am I missing 'something'?

Jay

[asmboy]

FYI- an overcompensated scope probe can make glitches on step edges too -
but its hard to beat a plug board for spike generation

[viki2000]

Here are my last observations over MCP4725 after a short test done yesterday and today.
I have tested the PIC Demo Board with PIC18F405K2, previously mentioned, with internal clock set at 64MHz using PLL. I measured the CLOCK OUT signal 16MHz (FOSC/4) to make sure I really have 64MHz inside the PIC.
I used a 9V battery with 5V 3-terminal regulator to make sure there is no ripple and noise from my 5V power adapter/supply.
When I zoom in with the oscilloscope at 1 step level of the signal, the noise is still there.
I have measured it with 2 different brand oscilloscopes, each with different probes.
I think it is due to high frequency of the I2C clock, maybe from inside the MCP4725.





Few weeks (or months?) ago I contacted Microchip to provide me an example about the 3.4Mbit/s of the MCP4725. The technician pointed fast to the MCP4725 board kits which they sell, but I told him that I checked their datasheets and is mentioned only 100KHz and 400KHz as I2C bus speed, so it makes no sense to buy and use them for test. I asked again about High Speed (HS) 3.4Mb/s example and since then a deep silence was laid.
Page 13:
http://ww1.microchip.com/downloads/en/DeviceDoc/51669a.pdf
Page 20:
http://ww1.microchip.com/downloads/en/DeviceDoc/51722a.pdf

Using PIC18F405K2 board at 64MHz I was able to increase a bit the speed on I2C bus. In software I was able to test “Fast=2250000”, so up to 2.25MHz, but in reality the I2C clock signal seen on oscilloscope was 1.6MHz.
I have reduced the pull-up resistors to 1K and later to 470ohm, but I could not g higher than the above limits.
Then for HS I have tried to add also the High Speed Master Mode Code as you may see disabled below code:

[asmboy]

so easy to clean up your signal.

http://sim.okawa-denshi.jp/en/OPstool.php

R1,2 =10k
C1,2 =100nF

one stage of this and your signal is perfect.

[viki2000]

Thank you for the calculated values, but my point this time was about maximum I2C speed, particularly how to achieve the 3.4Mbit/s claimed by MCP4725 and if there is any I2C MSSP hardware block inside to a PIC microcontroller to be able to run so fast and generally from where comes the limitations that I observed, because it seems a hardware limitation of the PIC.
I was thinking that having high speed between PIC and DAC, then I could increase the lookup table and I do not need any filter at all. It seems that I2C claimed speed 3.4Mb/s is not a good option when we refer at MCP4725 and we should stop at 400KHz; probably better results will be with SPI DAC, that I will analyze later when I have time.
Regarding your proposed values, they are good to smooth the signal, but they introduce some problems.
I have used MCP6002 OPAMP from Microchip. I have tried 1stage as you suggested, but also 2 stages.
The power supply is clean 9V battery with a + 5V 3-terminal regulator. The oscilloscopes were powered by a clean power supply, an AC programmable power supply with low distortion and the results are as you see below.

https://goo.gl/pqiWs7

There is an unwanted offset, even after the 1st stage of the Sallen Key filter. Besides that the waveform at the bottom, where it supposed to touch the zero line becomes more round instead of being sharp and the waveform per general becomes close to sine wave instead of rectified sine as I needed.
So, it is not good.
When you look from “distance”, zoom out if you want, with long time base for the oscilloscope, then the wave seems nice. But when we zoom in to look closely to one DAC step of the wave, then the noise can be still seen and measured. I have done that with 2 different DSO and different probes single-ended 1:10.
The noise is there and has around 12mV peak-peak roughly with possible maximum values of up to 35mV peaks and the period for one DAC step around 58us (frequency around 17KHz).

[temtronic]

As Mr. T points out there isn't a PIC that can directly intereface with the I2C DAC and go '3.4Mbps'. As he pointed out I2C needs active terminations...My 'gut' tells me thats a LOT of specilaized sillicon under the hood so wait3-6 months and maybe Microchip will announce a PIC with it....I wonder if any micro has AT and what the cost is...side point..
As for the wave form comments. What is the power supply feeding the op amp consist of? Are both feeds equal(say +5.000 and -5.000),Are they properly filtered,for LF,MF and HF noise? Are the caps and resistors for the filter equal(10K000 and 10K000, 100nf000 and 100nf000). Not trying to be 'smart' but if the component values are not identical, that will affect performance.I know that tolerence(10%, 5%) does !as wellas 'temperature range'. Every DAC chip requires some form of R-C filter as that's part of the Analog portion of 'DAC' unless the DAC operates at extremely high speed(100MHz) to generate a very low frequency(100Hz).
Creating 'A from D' is a challenging task, 1/2 pure math , 1/2 bench test, and 1/2 luck. There's a LOT to get right before it works right...even PCB design is 'fun'.

Jay

[viki2000]

[temtronic]

OK, I downloaded the DAC PDF...
some observations..
1) It says the Vref of the DAC is tied to VDD,so ANY variation in VDD( +5) WILL affect the DAC ! Yikes who in their right might thinks you can get 12 bit accuracy when you do that ,please raise your hands! The only way I could would be to use a precision reference device, with enough drive(current) to power the DAC as well as be the reference.It'd also have to be well filtered from the +9 source to insure ZERO ripple as ANY 'noise' will affect the DAC output.
2) Again, by the book, you need a 3K to 5K load on the output to keep it stable and accurate.
3)bipolar. I'm a 'dinosaur' and normally consider sine waves go +- from zero volts like 'Mains' power does.
4) your original post mentions a 1 v, rectifed output but your scope output links show a sine wave,so I assume you've not made that portion of the circuit?

Jay

[asmboy]

[viki2000]

Answers specific to your numbers:
1) I do not care at this moment about that. I think I will give up with this DAC. I was just interested to see from where comes the bottle-neck speed when I want 3.4Mb/s.
2) I have tried with different resistors as load, but no chance when I try with I2C speeds higher than 400KHz. As in my case I have tried up to 1.6MHz I2C clock speed – measured on oscilloscope, additional noise appears.
3) The offset may be compensated probably with bipolar, but I cannot have it. I can have only unipolar +5Vdc.
4) Indeed, what I need is 1V rectified wave. The sinewave that you see in my last screenshots is due to OpAmp, the Sallen Key filter, from where I have also the offset.
This waveform 1V rectified sine 100Hz should be generated different, not with this simple I2C DAC.
The I2C should be used up to 400KHz. Over implies special needs and I want a very simple circuit.
I was more pushed by curiosity, is not a real project, to understand and analyze where is the problem with HS 3.4Mb/s. Is it really the hardware or I2C subroutine?
I will come back later with a timing analysis of the code used. That would be the last attempt here to understand the HS 3.4Mb/s I2C.