Couple Q's about SBL 2e A/D's

[Vance G]

Had some time to experiment with the 2e's A/D's today.

the manual says:

"the value read is a number from 0 - 4095 representing the number of counts"

when using a Pxx? command when the pin is an A/D input.

I am not seeing that. What I'm getting is a 5 digit number that is very, very close to being the input voltage * 10000, i. e. when applying 1.5 VDC, a PXX? command will return (approx.) 15000.

Again, I feel I must be missing something obvious. I can work with the results I am getting just fine, but I am curious about the discrepancy btwn. docs & real-world...

[rnixon]

In the Freescale docs that come with the development kit it says the a/d result must be in the processor register must be shifted by 3 bits (same as divided by 8). The NetBurner docs or the app must be wrong in this case. Do the numbers make sense for your measurements if you divide by 8?

Theoretical Calculation:
4095/3.3V = 0.8mV per count
1.5V/0.8mV = 1861 counts

Your results:
15000 counts/8 = 1875 counts

So its in the ballpark.

[Ridgeglider]

Your post looks like you are using the web-based interface to the A2D where results should range from 0 to 4095. The web interface runs the following code where you can see the shift taking place:

short counts = ReadA2DResult(i) >> 3;

The count value is used to store a result into an array which gets averaged over time and stored in an int called avg.

The following converts avg to volts:
float volts = ((float) avg / (4095.0)) * 3.3;

If you have the development tools for the SBL2e, see: C:\nburn\SBL2E\system\A2D.cpp. If you are using the develoment tools, note that although there is a function called ReadA2DResult( channel), the result must still be shifted as shown above.

[Vance G]

rnixon, Rangeglider:

I am getting the values via a Telnet session.

Here's what I am doing as a real-world test of the A/D's:

Using a LM335Z temp sensor (10 mV / deg. K), taking the output of that, dividing it in half so as to not exceed the 3.3 VDC max input of the device.

The output of the 335 is correct for the temp. as measured with DVM. IF (big if) the 5-digit count I get is supposed to be a 10000X representation of the input voltage, it is always about
500 - 600 "counts" too high (after multiplying the result x2 because of the input voltage divider).

Is there some info on properly using the SBL's A/D's somewhere? Am I supposed to be doing anything special (I am directly connected to an input pin right now)? Should I just assume that the A/D's just aren't that accurate and that I am going to have to figure a scaling factor (the 500 +/- diff. I mentioned above)? The error is less than 2%, which leads me to believe that the designers were aiming for a "direct" voltage read of pXX? / 10000. Or at least that's what it looks like...

This is VERY different than my experiences with stand-alone A/D's connected directly to the system bus...

[Vance G]

Hokay, went to Freescale site and downloaded the 52235 manual. Read up on the ADC in chap. 28 and things are much clearer now.

The good stuff is on pg. 28-26. Those formulas summarized nicely what you all were trying to tell me.

I see a lot of "jitter" in the results - they rarely come back the same even back to back. I suspect this is why:
------------------
28.5.10 Voltage Reference Pins VREFH and VREFL

The voltage difference between VREFH and VREFL provides the reference voltage that all analog inputs are measured against. The reference voltage should be provided from a low noise filtered source capable of providing up to 1mA of reference current.

When tying VREFH to the same potential as VDDA, relative measurements are being made with respect to the amplitude of VDDA. It is imperative that special precautions be taken to assure the voltage applied to VREFH is as noise-free as possible. Any noise residing on the VREFH voltage is directly transferred to the digital result. Figure 28-28 illustrates the internal workings of the ADC voltage reference circuit. VREFH must be noise filtered; a minimum configuration is shown in the figure.
-------------------

"Figure" shows a LC filter on VREFH. I don't see any inductors on the SBL board

I know about the criticality of having a clean and stable VREF from my old bus-connected standalone ADC days.

I can work around it - my results only need to send back data in the range of 0 - 20VDC at a resolution of .1V (remote solar electric system monitoring). Connecting the A/D's directly to the supply voltage yields a result of 32760 as expected, and 0 when grounded. Maybe some light filtering on the input would quiet things a little...

Next hurdle: getting the results of the A/D onto a user-friendly Web page.

I looked around to see if there's any way to do that from TELNET directly - seems to be a big security issue and not easily done. At a minimum it would require end user to install Java, which they may not want to do.

You guys mention reading the A/D from the Web interface - and it sounds like that code is part of the Dev. Kit. Is that the only way to "see" that code? I bought the SBL bare not understanding the ramifications (learning FAST!) of going that route...the info on the site made it seem so friendly, I was sure I could work with it.

So, there must be some way to extract the A/D values from it besides TELNET.

Thanks for all your help so far, esp. the pointers about shifting the results 3 bits over. That led me to the manual.

[Vance G]

There's gotta be a way to get the A/D values out and into a web page.

Help an old hardware guy out here.

I am not looking to buy 1000's of SBL's for a mass produced product. I am one of several who live in an off-grid situation and want to "check in" with our solar electric systems when we are not there via Starband and control a few 802.11 radio links. When it's all said and done, we'll only need perhaps a dozen of the devices.

Buying the Dev. Kit for $299 kind of defeats the purpose of the $31.50 SBL as a cost effective solution for us.

Thanks for putting up with my whining...