[Tinyos-2.0wg] Concerns about ADC in 0.1mV

[Joe Polastre]

Why not a left-aligned 16-bit value with an optional "getRef" function
which is a 16-bit signed value that will return the ref in millivolts
or -1 if the ref isn't known?

-Joe

On 7/26/06, Prabal Dutta <prabal at cs.berkeley.edu> wrote:
> I think the real problem is making sure you know the value of Vref
> used for the A/D conversion.  If Vref is static, then that's great and
> an ADC count will suffice.  However, if Vref can change, then the
> conversion factor needs to be sent along with the ADC counts.  This
> approach allows engineering units to be recovered from the data and
> also minimizes conversion computation on the mote.  However, it might
> (a) not be supported in all platforms (if Vref can't be compared to a
> bandgap reference) and (b) could require two ADC conversions -- one
> for the signal and one for Vref.
>
> - Prabal
>
> On 7/26/06, Martin Turon <mturon at xbow.com> wrote:
> >
> > I totally agree with Gil here.  Typically we have seen deployments where
> > the motes send raw samples in fixed point, and the conversion happens on
> > the gateway or client application.  There are a few benefits to this:
> >
> >        - less power/speed hit on the mote hardware
> >        - reliable data -- no doubt about whether mote conversions are
> > correct
> >        - standard data -- fixed point is more standard than floating
> > point
> >
> > Left shifting the samples is fine, as is providing knowledge of the
> > reference voltage, but actual conversions should probably be left out of
> > the ADC interfaces.
> >
> > Martin
> > __________________________________________________
> > Martin Turon  |  Crossbow Technology, Inc.
> >
> > -----Original Message-----
> > From: tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU
> > [mailto:tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU] On Behalf Of
> > Gilman Tolle
> > Sent: Wednesday, July 26, 2006 12:44 PM
> > To: tinyos-2. 0
> > Subject: [Tinyos-2.0wg] Concerns about ADC in 0.1mV
> >
> > Upon first read, the proposal to return ADC HIL values in 0.1mV
> > sounded great. After thinking it through a bit more, I have a few
> > concerns.
> >
> > We're going to lose information during the conversion and rounding to
> > the nearest 0.1mV, simply because we don't have enough decimal places
> > to maintain the actual voltage. The uV proposal would certainly help
> > with this problem, at the cost of engaging 32-bit math and doubling
> > the size of the samples. Even with uV, we'll still hide information
> > about the precision of the ADC.
> >
> > This proposal assumes people are going to want to translate from
> > voltage into engineering units on the mote. So far we haven't seen
> > much of a demand for this, likely resulting from the heavy math needed
> > to do these conversions. The closest need we've seen so far is
> > converting the output of the battery voltage sensor from ADC units to
> > voltage, to be used in a check before performing flash memory
> > operations. For that purpose, TinyOS 1.x only performed the conversion
> > when reading from a battery-voltage HIL called VoltageC, not for every
> > ADC operation.
> >
> > For high rate sampling, performing the conversion for every sample
> > when using ReadStream will impose some non-trivial CPU performance
> > penalty. This feels analogous to the earlier discussion about
> > left-shifting the read results. For something like audio data, the
> > processing algorithms may not even need true voltage, if fractions of
> > full-scale is enough and full-scale is known.
> >
> > At least no information is lost with left-shifted ADC readings, and
> > the differences in ADC precision are still abstracted away. Although,
> > we still pay the cost of the left-shift, and actual precision must be
> > exposed through another interface to support the processing steps that
> > care.
> >
> > We should check with some sensing domain experts to see whether the
> > rounding error, information hiding, and conversion costs would be
> > acceptable.
> >
> > Gil
> > _______________________________________________
> > Tinyos-2.0wg mailing list
> > Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0
> > wg
> >
> > _______________________________________________
> > Tinyos-2.0wg mailing list
> > Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
> >
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>