HIGH LIMIT 1 (PAGE 0x05) Registers Settings

Hi junboyi@bluedanube.com ,

thank you for your question, please refer to the AD7293 datasheet (DS), "Internal Channel Monitoring" section, which describes scaling of each of the mentioned channels. (Fugure 42. attached for your convenience, which reflects the same, more detaild description is in DS.) Resulting codes are then compared to determine, if ALERT will be triggered based on the configured limit. 

Regards,

Arnost

If I need to figure out how to map the input to Limit Register ADC data, then I don't need to ask questions here.

As user, I would like to have a simple, direct conversion between input voltage range to Mux range, especially for those with negative voltage range.

Thanks.

JYI

Hi junboyi@bluedanube.com ,

maximum range of -7V is "maximum rating" to prevent destructive effect take place.

GENERAL - POWER REQUIREMENTS table indicate AVSS to be in range of -5.5V to -4.5V (or 0V).

DAC - DAC OUTPUT CHARACTERISTICS indicates DAC output voltages, where maximum negative output is -5V.

Even when AVSS is -5.5V, maximum DAC output voltage is -5V.  

Regards,

Arnost

I see.

Thanks.

JYI

Is possible to keep Alert Summary and the corresponding alert registers not to be reset until a '1' is written to, even the alert condition is gone?

Thanks.

JYI

Hi junboyi@bluedanube.com ,

I am not certain if AD7293 will be able to perform exact functionality you are looking for, however I would suggest to explore possibilities of using "mask" registers and "alarm routing" to alert pins. 

This might help you in your system application.

Typically "Alert Summary" will be created and kept in the controller, by reading "all necessary" alert registers, when alarm is triggered. 

Regards,

Arnost

Thanks.

The reason I asked this question is because the similar TI chip we have been used on our design has such functionality to allow host controller to get alert status even the alert condition is done.

JYI

Hi JYI,

Perhaps I haven't understood you question fully and what you are trying to achieve.

Do you meant, that you want "alert" to be set once triggered, and to stay set even when "fault/out of limits" scenario is no longer present. In such configuration alert will stay set until manually cleared by the user. (by writing 1 to corresponding alert bit).

Such functionality is available at AD7293, you can find it under hysteresis for alerts, program hysteresis to big enough value to corresponding alerts. Perhaps 4096 (full 12-bit range) in your case, and alerts once triggered will stay on, until manually cleared.

Hope this helps. 

Regards,

Arnost 

Thanks for your response.

The description scenario in your email is what I mean exactly.

In our new design with AD7293, the alert pin is routing to sleeping pin to clamp the PA bias when the alert is triggered, such as bias current over driven. But once clamped, the bias current is down to zero, then the alert condition is gone, and the alert registers are reset. As the result, the host controller is unable to know what is happening even though it is noticed via alert signal, such as by interruption. 

This is what I am looking for the solution for this scenario. I will try to use the way you suggested.

JYI

Testing alert functionality on AD7293 EVAL Board according to your suggestion.

Feeding UNI-DACx output to VINx and set VINx High Limit to 2V and VINx Hysteresis to 0xFFF (Register Read as xFFF0).

Set UNI-DACx output to 2.5V -> VINx over High Limit -> Alertx Pin asserted (active LOW) -> UNI-DACx Output 0V (Clamped) -> Alertx Pin LOW last about 50-micro-second -> Alertx Pin deserted (idle HIGH) -> UNI-DACx Output Keeping 0V (Snooze Enabled).

Alerte Summary and Alert Status Reset (Read Register 0x0000).

This result is not what it should be as the one described on your response and is not what I expected.

Is something missing?

Thanks.

JYI

Set Hysteresis x7FF (Register read back x7FF0), not xFFF keeps alert Pin and status registers un-reset even the alert "fault/out of limits" scenario is no longer present. Verified for VINx and BI-VOUTx, but failed to find such as description on data sheet. Not sure it is true for all alerts.

JYI

Measurement of the period from the out of limit to alert pin asserted is about 300 micro-second with only one background channel enabled, such as VIN0. Increasing to two channels double this period.

The ADC sample and conversion period should be less than 15-uS based on the data sheet. The 300-uS from alert condition triggering to alert pin assertion is normal for AD7293 or it can be shorter by the configuration.

What is the fastest alert response timing for AD7293 for single monitoring channel? 

Also, if snoozing disabled, the alert pin asserted period is much shorter than the deserted period. Should these two periods be the same based on ADC sample and conversion time.

JYI

Measurement of the period from the out of limit to alert pin asserted is about 300 micro-second with only one background channel enabled, such as VIN0. Increasing to two channels double this period.

The ADC sample and conversion period should be less than 15-uS based on the data sheet. The 300-uS from alert condition triggering to alert pin assertion is normal for AD7293 or it can be shorter by the configuration.

What is the fastest alert response timing for AD7293 for single monitoring channel? 

Also, if snoozing disabled, the alert pin asserted period is much shorter than the deserted period. Should these two periods be the same based on ADC sample and conversion time.

JYI

Hi JYI,

I apologies I will need to look into this query and come back to you by end of the week.

Regards,

Arnost

Hi JYI,

my apologies for late answer, I have been looking into your query. Would it be possible to clarify, what mode of operation are you using for initiating a conversion. (As per Datasheet [DS] page 72.) Aren't any other conversions enabled such as Curren Sense monitor or Temperature monitor? 

Typical conversion time in DS for Command mode at Vinx is shorter (~0.7us) than Background Mode (~2.3us).

Knowing your configuration will be appreciated, that will help me to eventually find out, reason for the timing you are indicating. 

I would need to investigate these queries on the bench.

Best regards,

Arnost