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

[Joe Polastre]

getTimestamp() in SP, for example, is only valid until the next packet
is received.

I see no problem with it being on a per-sample basis and it disappears
if you never use it.

-Joe

On 7/26/06, Prabal Dutta <prabal at cs.berkeley.edu> wrote:
> Wouldn't the Vref be associated with the sample and not the ADC
> interface since it can change between calls?  Joe's approach might
> work with some caveats: the getRef call could be valid until the
> associated readDone event returns.  That is, getRef would have to be
> called from inside the readDone event handler.
> Otherwise, Vref for the particular call could be lost forever.
>
> - Prabal
>
> On 7/26/06, Joe Polastre <joe at polastre.com> wrote:
> > 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
> > >
> >
>