• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 182 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AMC6821 PWM cycling

AMC6821: Surging fan (3-pin fan)

Aron Lander
Prodigy 10 points
Part Number: AMC6821

Hi,

I'm trying to measure the rpm from the tacho signal with an amc6821, using a 3 pin PWM fan (1200 mm, max rpm = 3100), however, I'm unable to get it to not surge during the measurements (my issues are similar those described in: https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/107812/amc6821-pwm-cycling). The mode it's running in is

The settings I'm running:
* TACH-EN = 1
* PWM-ON = 1
* TACH-MODE = 0
* PWMINV = 1 (due to our setup, the PWM should indeed be inverted)
* FDRC = 11 (i.e. the operation mode is to act based upon the temperature measured)

I've tested various different PWM frequencies, interestingly enough with different results:

With the PWM mode pin connected to ground:
* 25 khz - Surges a lot, getting rpm readings which are completely off
* 1 khz - Surges (less surging than 25khz though) and sings (not suprised, 1 khz is within the audible spectrum), getting a lot more probable rpm readings

Pwm Mode left floating:
* 94 hz - Sings, a lot less surging, probable rpm measurements
* 30 hz - Makes clicky noises, probable rpm measurements
* 10 hz - Even clickier, probable rpm measurements

Considering that, from what I can see in the datasheet, the amc6821 will need to keep the PWM signal high during the measurement (which is understandable due to that the fan need to be powered to emit a tach signal in the first place), I wonder: is it possible to avoid surging at all when running a 3 pin fan or is it unavoidable due to the fact that the signal needs to be held high while measuring?

  • +1
    TI__Mastermind 41065 points

    Hi Aron,

    Do I understand correctly that your fan is 1.2 meters, nearly 4 feet, in diameter? The AMC6821 would need a significant power stage to drive this fan with its PWM. I have to assume the issues you're seeing are a result of this power stage circuit. There may also be a lot of induced noise in the TACH and/or remote temperature signals. Could you please:

    1. Check behavior in the other FDRC modes Software DCY and Software RPM. In the temperature control mode, the PWM may vary due to noisy TACH and temperature readings. In software RPM mode, the PWM may vary due to noisy TACH readings. In software DCY mode, the PWM frequency will be constant. You can configure various PWM DCY directly and check if the noise is always an issue at certain settings. You'll need to determine if these temperature/tach feedback loops contribute to your issue.

    2. Have a look at your circuit with an oscilloscope. The power stage may not have the bandwidth, or the interaction with the load may not allow it to be cycled by a PWM. You would see ringing, settling and/or instability issues when the PWM duty cycle is applied. These issues won't go away in the software DCY mode, so you can explore them there. 

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Prodigy 10 points

    I'm sorry, my bad, an additional 0 got in there (the fan is 120mm; can't even imagine what the power consumption of a 3100rpm, 1.2m fan would be...).

    Anyway, thanks for the suggestions, I'll try them and see what I can find.

  • 0 in reply to Aron Lander
    Prodigy 10 points

    So, when trying to run it in software DCY mode, I noticed that the surge only appeared when bit 0 was set in config register 1 (addr 0x00); running it with temperature measurement and tach measurement disabled removed the problem.

    After hooking up an oscilloscope as suggested, the readings on the tach signal did indeed look rather malformed to say the least, so this points to that being the culprit.

    Thanks for the help!