[Tinyos-2.0wg] Concerns about ADC in 0.1mV
Philip Levis
pal at cs.stanford.edu
Tue Aug 1 12:36:12 PDT 2006
On Jul 29, 2006, at 3:06 AM, Vlado Handziski wrote:
> Sorry for the late reply, but the last few days have been very busy
> for me.
>
> I think Parbal has summarised very well the arguments why a plain
> uninterpreted result from the ADC is not enough for conversion into
> final engineering units. Gil and Martin are right that the current
> solutions perform the conversion at the edge of the network, but
> this works correctly only for a limited set of scenarios where the
> network is homogeneous, and the sensors are in a ratiometric setup
> or powered and sampled using stabilised voltage reference. In all
> other cases one needs additional local information (like the
> voltage reference and/or the way the sensor is connected) in order
> to properly convert the output value from the ADC into the final
> engineering unit. A top level ADC abstraction will have to either
> use this information internally and produce an absolute value like
> in our original proposal, or provide the relevant local information
> in addition to an uninterpreted ADC output like Joe proposed
> (although in some cases just knowing Vref is not enough).
>
> I agree with Gil that the price for the conversion on every sample
> might be more than what we are willing to pay especially for
> ReadStream-like usage, so let's keep an uninterpreted interface for
> those cases. But the fact remains that a relevant local info is
> required to properly convert into engineering units when the
> application needs this.
>
> I think that this local information should be folded in into an
> absolute value on the data path as soon as possible. In other
> words, I would prefer if the ADC HIL does this conversion. It
> already has the relevant configuration information from the
> platform component (that was used to configure the ADC chip for the
> conversion) and is in a position to obtain an estimate of the un
> stabilised supply voltage (battery) in case the sensor wiring is
> such that the output value of the ADC requires correction (non
> ratiometric).
>
> Alternatively, the conversion into an absolute value can be
> performed in the "platform" component, using the uninterpreted
> output of the ADC, the local configuration information and supply
> voltage estimate when needed. But if this is something that needs
> to be done for several sensors, for me it makes more sense if we
> centralise this into the ADC HIL.
>
> I am also attaching a short writeup on the way I see the separation
> of the responsibilities between the 3 players: the sensor driver,
> the platform configuration component and the ADC HIL.
>
> Jan is working on preparing concrete proposals for the signatures
> of the ADC HIL and the other components that take into
> consideration the concerns that have been raised in this thread. I
> hope that we will be able to reach a satisfactory compromise.
>
> Vlado
>
>
Given that this is a pretty important discussion and that TEP 101 is
currently in the finalization process, I'd like to make sure that we
don't drop it.
I think it makes sense for the HIL to output millivolts/microvolts,
etc. The sensor driver is what then converts that into units, based
on the input voltages and knowledge of the transformation function.
I think that it also makes sense to provide the "uninterpreted"
reading, in case there is something special going on. However, I'm
not sure that it makes sense to provide this at the HIL level, rather
the HAL seems to make more sense. If you're doing something special,
you're platform specific.
With the configure interface, you know what the voltage reference is.
So you should be able to do the conversion. It would seem to me (and
I'm not completely sure, am skating at the edge of my understanding)
that any limitations here are those of software structure and not of
fundamental problems.
I think that new special interfaces for getting the Vref, signaling
vref change, etc., don't make a lot of sense, especially at the HIL
level.
Phil
More information about the Tinyos-2.0wg
mailing list