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.
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.
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().
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?
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.
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)
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.
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.