Reading ADC value from Q2686

Hi,
can someone tell how to get the adc value using the “adl_adcRead”? The syntax is “s32 adl_adcRead (u32 ChannelID, u32* AdcRawValue );” But, what is the channelID that has to be sent? Is it the ADC pin number which is 21 or is it the parameter value equivalent to the at+adc?
Expecting a reply at the earliest.

the parameter value equivalent to at+adc seems the most likely to me,
Have you tried it? (most of the times way faster than to wait for a forumreply)

actually it’s even in the documentation.
Notes:
• ADCs will be identified with a number as 0, 1, 2, . . . . adc_NbBlocks-1.
• For each block, the sampling time capability is defined in the PTS.

Here is all you need to read either the actual millivolt or the raw ADC value from the 2nd ADC (ADC2 or AUX ADC) on a Q2686, using v7.1 firmware.

#include "adl_global.h"

const u16 wm_apmCustomStackSize = 1024*3;
s32 MilliVolts;
u32 ADC_Raw;

void ADC_Read (u8 ID)
{
	adl_adcAnalogRead( 2, &MilliVolts);
    TRACE((1,"ADC mV: %d", MilliVolts));
	adl_adcRead( 2, &ADC_Raw);
    TRACE((1,"ADC Raw Value: %d", ADC_Raw));
}

void adl_main ( adl_InitType_e InitType )
{
    TRACE (( 1, "Embedded Application : Main" ));
    adl_tmrSubscribe(TRUE, 20, ADL_TMR_TYPE_100MS, ADC_Read );
}

ADC value is read every second, and result is shown in trace.

Thanks all for the immediate reply. It’s really helpful. Let me try it out and get back on this. I have few more queries wrt GPIO handling.
Do we need to subscribe to adl_ioeventsubscribe if we are going to poll for GPIO values periodically?
Also, can we use >1 adl_iowritesingle commands continuously in the code will it affect the way the GPIO pins are enabled in anyway?
How accurate are the adc values? I have this Qn as there was some high error percent in the adc values obtained from Q2501.
Few general Qns as well:
Can we configure the timer handler to 5 secs? Or should the interval be some higher value?
Has anyone faced issues while using DOTA in Q2686?
Need help on the hardware and software watchdog timer handling. Sample code on this will be really helpful.
And, im using Q2686 with OS R70 version and 2.12 IDE.

Regards,
S. Vanee

No, if you want to manually poll GPIO values, you don’t need to subscribe. In order to set-up an automatic GPIO polling process, the adl_ioEventSubscribe() function has to be called before the adl_ioSubscribe().

The smallest timer value is 18.5ms. Don’t know what the longest timer value can be.

guess you can use its as many times as you like, as long as you have subscribed the GPIO pins you are writing to using adl_ioSubscribe().

longest timer is in the direction of day’s.

although it’s NOT apparant from the documentation.
adl_ioWriteSingle is depricated and will be removed in the future.

Thanks for the useful tips. can you send some sample on how to use adl_iowrite() say for using GPIO 1 and 2 as output and 21 and 32 as input?
Also, did anyone face issues with DOTA in Q2686?

Hi,
will there be any difference in the adc value read using adl_adcRead() and at+adc? or do they both give the same values?

Pls do reply at the earliest.

here should be no difference, the analog value (or ‘raw’ digital value) is comming from the same internal registers.

That means if there is a correction factor required when we use at+adc, the same will apply to adl_adcread() as well? Then, what is the need for having a separate api? Is there any performance advantage?

I don’t know about you, but i really don’t like to mess around with having to send at-commands from my program to the Open-AT OS and then having to interpret the results.
a simple api-call is much more desireable (would really like to have them for all available at-commands)

it’s like you have two way’s to accomplish the same thing, (as with all the AT-commands which interface with the GSM/GPRS parts of the module)

Do you not find that it is easier to simply make an API call like adl_adcRead() rather than having to issue the AT command, and then handle the response?

There is, of course, nothing to stop you from just issuing the AT command and handling the response - if you find that preferable.

I thoroughly agree!

See: viewtopic.php?t=1171&hilit=mess+about+with+AT+commands

Thanks for the suggestion. But, why i asked the question is because, the adc value read using at command is not accurate hence, had a hope if the adl command would solve this issue. The adc value read using at command has an added value of approximately 20 to 60 values for a value of 4mA - 20mA resulting in 420 - 460 as opposed to the expected to the 400 value. Does any know why this problem occurs and how to rectify it? Do we need to use external chips via I2C to read the adc?
Pls do reply at the earliest.

I seems that there is no way to change the calibration for the internal adc’s. So if you need to change the offset of the adc’s then you need to compensate in your code or indeed use an external adc (can be connected trough I2C or SPI)
added advantage of an external adc is that you have much greater control over it’s parameters. (offset, calibration, range, etc)

But the ADC measures voltage, not current - doesn’t it?

So, have you confirmed that the error is really in the ADC reading - or is it actually in your current-to-voltage conversion?

Is it within the quoted specifications for the ADC?

Where do i find the specifications for ADC? im confident that the ADC reading is causing the problem. To cross check, is there a way to find out where the problem is if it is in the adc or in the current-voltage conversion? If it is measuring the voltage supplied, then we have done this. And the conversion is quite accurate.
Also, i would like to know if Q2686 has different way of handling ADC than Q2501 or is it the same? As we faced this issue a lot with Q2501.

In the Product Technical Specification - or PTS.

So the ADC is accurately converting the voltage supplied to it? What more can you expect?

The ADC cannot see anything other than the voltage applied to its input!

So the ADC is accurately converting the voltage supplied to it? What more can you expect?

The ADC cannot see anything other than the voltage applied to its input!
[/quote]
i suspect that the conversion he’s referencing to is the current to voltage conversion.

Sorry there’s mis interpretation of what i said. It’s actually through external means we measured the voltage going into the chip and that is accurate. But, what comes from the Wavecom chip via ADC’s having the issue that i have been mentioning.

“The adc value read using at command has an added value of approximately 20 to 60 values for a value of 4mA - 20mA resulting in 420 - 460 as opposed to the expected to the 400 value. Does any know why this problem occurs and how to rectify it?”

And interestingly one of my friends working on Wavecom has also been facing this issue. Pls do reply at the earliest.