Post Go back to editing

Output Frequency of CN0349

Category: Hardware
Product Number: CN-0349


my question has been asked several times in different versions, but none of the answers given seem to help in my case. My problem is the output frequency of "vanilla" CN0349 Boards. It seems to me, that with the 1Mhz oscillator connected to MCLK of the AD5934, it is not possible to programm any values greater than approx. 7250 Hz into the Start Frequency Registers. My logic so far is that with the euqation given on page 13 of the AD5934 datasheet, the maximum value programmable to the AD5934 in Hz, which is still <= 24 Bit is about 7250. I came across this problem, because my measurements were consistantly wrong and all of them wrong in the same way. Now i've tested this theory and so far it seems to be true. As long as i program values below the 7250 Hz threshold, i can use the registers and get the desired output frequency. BUT for some unkown reason, which i cannot find an answer to, at about 30 kHz the Board just randomly changes direction and lowers the frequency instead of increasing it.

Now it would be just great if anybody could help me out. My 2 questions beeing:

1. Am i right with my assumption that with the given equation on page 13 of the AD5934 datasheet, it is not possible to programm values greater than ~7250 Hz, since this is the maximum value still equal to/under 24 bit?

2. Why is it not possible to increase the frequency above 30/31 kHz? Are there any ways to work around this problem?

If you have any questions i will gladly answer them.

Thanks in advance.

  • The maximum frequency you can get from the AD4934 is by writing 0xFF into all 3 registers.  With the 1 MHz MCLK frequency used  on the CN-0349 board, from the formula on page 13 of the datasheet you mentioned, the AD5934 would produce the maximum frequency of about 7812.5 Hz.
    To make the board operate at 30 KHz it would be necessary to remove the U6 FXO-HC536R-1 1 MHz oscillator and replace it with a higher frequency one (for example, FXO-HC536R-16) or wire in the MCLK signal from some higher frequency external source such as lab generator, etc.
    If the datasheet 16 MHz MCLK frequency is used, the maximum frequency the AD5934 would be able to generate is about 125 KHz.    

  • Thank you so much. I just dont understand how someone would NOT write something like that in the datasheet. Would have saved me days of work finding that out the hard way..

    Anyways, thanks again.

  • Yes, unfortunately the documentation is not clear and there are quite a few behaviors in this chip family that are completely undocumented. Bumping into those in the middle of a project does create serious setbacks. Documentation limits marketplace acceptance of these otherwise rather unique chips.
    Best of luck with the rest of your project, please do not hesitate to ask if you have any further questions. 

  • I had a look through the Circuit Note and the datasheet. It is true - it would have been a good idea to explicitly state the frequency range and resolution of the CN0349 given the 1 MHz master clock. It also looks like there's little to no mention of changing the frequency from a default value of 2Khz. The only mention in the note is "This oscillator allows the AD5934 to excite the conductivity cell with a frequency of 2 kHz, which is well suited for conductivity measurements." (Does the supplied GUI even allow the frequency to be changed?) Again, I absolutely agree that this should have been documented better in the circuit note.

    But I don't see any ambiguity in the AD5934 datasheet - all formulas are expressed in terms of  MCLK frequency, with 16 MHz used as an example. The last paragraph on page 29 also explains when you might want to use a lower MCLK frequency.

    I dug into the no-OS and Linux driver documentation as well. The only bare metal drivers for the AD5934 seem to be here: . (note the title is actually for the AD5933.) This should be considered legacy code, any new development would be in the no-OS repository. It looks like the AD5933 IS supported in no-OS, and the exernal clock frequency is defined here:

    and can be changed through the driver functions:

    Similarly, the external clock must be defined for the Linux driver:

    Once the MCLK is defined for these drivers, you should be able to set / read back the frequency properly.

    Acknowledging this was frustrating for @muzot , hope this helps in the future.


Reply Children
  •  all formulas are expressed in terms of  MCLK frequency, with 16 MHz used as an example.

    Indeed those formulas seem relatively straightforward, but evidently not to all users. 

    The last paragraph on page 29 also explains when you might want to use a lower MCLK frequency.

    The last paragraph on page 29, however, is an example of a rather ambiguous text: it refers to 16.776 MHz as the "nominal clock frequency," while the rest of the datasheet text uses 16 MHz as typical MCLK frequency. 16.776 MHz is the frequency of the AD5933 internal oscillator, so this is the frequency that cannot "be scaled down" as it is not under user's control. When this passage is found in the AD5934 datasheet it is even more confusing as the AD5934 does not have the internal oscillator. And nowhere in the AD5934 datasheet it says that on power up the chip is set to operate from the clock coming from this non-existent internal oscillator. Naturally, this clock is not coming and the chip appears dead. So it is user's responsibility to enable it's operation from the external clock by programmatically setting bit D3 in the control register, but how one would know?

  • This is more of an after thought, but I turned that formula into a little Excel spreadsheet to help with some quick calculations based on the MCLK frequency.  Note this doesn't take into consideration any absolute maximum inputs/outputs, its purely that equation just solved for Fout.XLSX

  • Agreed.

    In an ideal world, the customer shouldn't be have to pick through every bit, there should be device drivers that handle that sort of thing.


  • Well yes and no. I am writing my own drivers and external drivers would be great as a reference but they would not help me out directly. A correct datasheet on the other hand would have saved me days and weeks of work on this project. There are so many "mysteries" regarding just this frequency topic that its mind boggling to me.

    From a customer/engineer point of view:

    As I read through the datasheet (AD5934) for the first time, I was certain that the clock speed was at 16.776 Mhz as it was stated. There was no mention of the AD5933 and I only realized that this was nonsense after i read an answer to a different question from . After going through my entire project and changing everything to 16 MHz (again, as stated in the datasheet) I was certain (again..) that this was the right way to do it and that it would solve my problems. There was no mention of another clock beeing connected to MCLK other than a 16 MHz one (to be fair enough, it is stated in the CN0349 datasheet, but not in a way you would remember after reading through many pages of two different datasheets) and tbh my only explanation would be, that it wouldnt sound as great if you wrote down that this "vanilla" device only manages to get up to a frequency of about 30 kHz (which i wouldnt have minded were it written down). There is NO mention (and i mean absolutely no mention) of a 1 Mhz clock changing the output code after the calculations mentioned on page 13 ff to a message greater than 24 Bit, which means you cannot "normally" (as in: described in the datasheet) write your start frequency / increment to the registers. Besides the many hours I had to put in just to fully understand what is meant by all these vague statements i had to change my code and setup mutliple times for no apparent reason.

    Which is just my point. This device is great. It does what it should and it works exceedingly well. IF you know how to use it. Which requires a readable, understandable datasheet. There are many more ambiguous statements (not just regarding the frequency). It would be just great if these datasheet were written from a customer POV, so someone who bought this product could actually use it right away without finding deviations for no apparent reason.

    Sorry for this rant but as you can see there was quite some steam building up. If you or any other Analog folks are willing to work these problems out, i am sure myself or even are more than willing and able to help write these datasheet in an understandable way to improve the customer experience.

    Anyways, thanks for all your help again. It seems to work for now and if I stumble upon any more problems, I will contanct you guys again.

    Have a great day,


  • there should be device drivers that handle that sort of thing.

    The overwhelming majority of users corresponding in this forum on this subject are building their systems with standalone microcontrollers, Arduinos, etc. directly communicating with the chip. Very few are using the evaluation board - there seem to be no use cases for these chips that would involve PC. Some look for ways of hooking up Arduino I2C lines directly to chip bypassing the board controller of the eval board and, perhaps, sidestepping driver issues.

  • Sorry for this rant

    No need to be sorry - it is important to provide honest feedback. Many forum participants seem to give up on their projects  based on these chips after similar experience. It is extremely frustrating typing in the higher frequency only to see the chip generating a lower one because the the resulting codes were longer than 24 bit and got truncated at the top without a warning and this behavior not mentioned in the documentation. Imagine how many more outside this forum tried and gave up - not everyone has your stamina to wrestle with this for weeks and write a page-long assessment. 

    Best of luck with the rest of your project, hopefully it is going to be smoother sailing from here. Please keep in touch in case some underwater rocks come up.

  • Well yeah exactly. I am going through posts on this site for quite some time now and i cannot understand how the datasheet was never updated altough so many people stumble upon the same problems...

    Anyways, one question occured after changing my setup/code. For some reason the real/imaginary data i read out after reaching the last increment point (Frequency sweep complete) is always wrong and thats the case for every voltage. Doesnt matter which frequency is the last measurement point. I can easily work around that by programming one more increment number into the register so it never reaches the "real" last frequency point. Would still be interesting to me why this problem occures.


    Thats probably not the real problem. It seems like the real/imaginary data i can read out after increasing the frequency thorugh the sweep options changes in a static way. What I mean by that is that no matter where i start, I get the same results. Always starts with the desired cell constant of my conductivity probe and then the cell constant slowly decreases (i wrote an algorith which goes through all frequencies and voltages to find the optimal setup). Initally i thought this is an effect of the change in frequency which obiously changes the measured resistance in sulution but the fact that it doesnt matter at which frequency i start/stop is just strange.. Doesnt even matter what the amount of frequency increment is.

    As for my routine:

    1. Calibrate the GF/NOS etc for both realms and all voltages

    2. Send frequency data

                measure temperature

    3. Initialize (standby, init, start)

    4. read out data (check res register, get res)

    5. increase frequency

    6. repeat frequency for all voltages

    7. start at 4 again

    Is there something fundamentally wrong with this routine?

    I checked if the output frequencies/voltages are right multiple times and they are. Can't quite figure this one out.

  • There seems nothing wrong with the routine. Conductivity measurements can be tricky as the measurement cells tend to drift, especially with aqueous solutions. Hard to give any useful recommendation not knowing enough about your particular setup. As you apply different excitation voltages across your cell, depending on the nature of your electrodes at higher voltages you might trigger some electrochemical reactions that are likely to affect your results.
    If you have access to an oscilloscope - as your circuit goes through the measurement routine - it is always a good idea to check the voltage waveform at the AD5934 RFB pin and at the output of U2B OPAMP - those should nearly identical (ignoring 180º phase) well-formed sinusoids without any distortion or clipping at all frequencies and voltages. 
    Generally speaking, it is useful to keep some linear "equivalent load" with the impedance similar to the expected impedance of your cell, usually a resistor or a sequential RC. If the results from the cell look strange, it is always useful to connect this "load" and see if the circuit performs as expected with the load, then the issues are with the cell and not the electronics.
    Feel free to post your data through Insert- > Image/video/file as a text or csv file if you think it would be useful for somebody to look at it. Re and Im data as it comes from the chip, prior other calculations, would be particularly useful.

  • Thank you for your reply! As this is a work project I cannot disclose much more than I already have.

    What exactly do you mean by equivalent load? Would a precision resistor be enough? I have not yet tried that for some reason, but I will do so today or tomorrow and tell you how it went.

    I will also check the outputs of the RFB and OPAMP output Pin. If these waveforms do not match or do not look good, what exactly would be my conclusion? Something wrong with the chip itself?

    As for the voltage part and electrochemical reactions, it is not entirely unprobable but I would highly doubt effects like these taking place in standard KCl solutions. Nethertheless, I will start with a measurement with the low voltages (0.2 and 0.4 V) to test this.

    Thanks again.

  • Ok so i checked if everything went fine with a resistor connected to the pins for the cell and i had no problems measuring the right value across the entire voltage/frequency/realm range. After doing that i connected my cell again and lo and behold, it worked fine. Probably a faulty cable of something like that.

    So the problem is fixed for now / never existed.