Analog UV sensor

edited February 2015 in Android
We've connected this sensor: to the board(pin 0). When requesting data from that pin we get voltage of ~4000 mV in the dark and ~5000 mV on the street, which doesn't make sense according to sensor description. Voltage of 5V will mean UV index of 50, which can't happen. On the other hand when measuring sensor output with multimeter everything works fine.  What could be the issue? Is there some additional info I need to provide you with?


  • My original description is a bit vague. So we double-checked today, when we connect UV sensor to Metawear, application delivers voltage value of about 4V from a sensor. When we measure voltage on a pin with multimeter, it's ~0.1V. So we think the problem is with Metawear. We tried two boards, and result was the same. The third board is on the way, but if it doesn't work, we're out of options. 
  • Igor,
    Remember that MetaWear is a 3V tolerant board, not a 5V board. Basically it can't take any inputs higher than 3V or measure them through the ADC (the reference voltage is 3V so it doesn't have measurable values for anything higher than that). You will have to adjust your circuit accordingly.
  • edited February 2015
    Ok, but then why I have output of 4-5V depending on the UV intensity? 
  • I don't think I understand your question here
  • @Laura ;
    I mean, if Metawear is 3V board, how come I receive values of 4-5V when querying GPIO module in the app? 
    I'm not a hardware expert, so forgive me my ignorance. 
  • You aren't. 
    You receive values that are relative to a reference/supply/base/system voltage, in the MetaWear case, it is 3 Volts.
  • edited March 2015
    Hey Laura.
    Our UV Sensor is supplied by Metawear board (3V) directly. It is an analog sensor with an opamp which works as a transimpedance amplifier. We think that your Metawear board works with a 10bit ADC (it also can be configured as 8bit ADC, afaik). With a multimeter we measure 10mV offset on sensor's output in the dark. So, digitized value should be b000000011 (3). Our question is now, why do we read 4V at the Metawear iOS app although the sensor is supplied with 3V and cannot output any higher voltage? Maybe these value is not voltage based but just the decimal ADC reading?
  • Hi @igor_filippov, @erwin,

    @erwin, you are correct, MetaWear is digitizing using a 10-bit ADC.

    It should not be possible under any circumstances for the API to report 4V on an ADC input, so we must have an issue somewhere.  Could you post a short code snippet with how the sensor is being read?

    Some simple sanity checks would be which pin index is being used, and whether the pull up or down on that pin is disabled.  In some of our own testing we use the pull ups to force and ADC pin high or low and check that it is reading properly.

    Regarding the ADC value output, we have two modes of operation:
    1.  "Supply Reference" mode produces a standard 10-bit ADC output measured against the 3V supply. This is good for measuring things like a resistor divider, which is powered by the 3V supply, because any variation in 3V will affect both sides, effectively "canceling" the error.
    2. "Absolute Reference" mode produces an output integer in mV.  To do this, we are measuring the input against an internal voltage reference, and computing the output voltage in absolute terms. This mode is better for sensors that provide an output in absolute voltages rather than supply referenced voltages, like the UV sensor being used.
    In any case, the API should not be able to read 4V ever, so there is an issue.  A code snippet or other detail showing how the 4V results will help us get this resolved.


  • Another user has brought a similar problem up and it turns out the sample app is using outdated callback functions which incorrectly interpret the data coming from boards with firmware v1.0.0.  An update has been pushed out on GitHub (commit 4cb9fe6e) to address this bug as part of the next app release.
  • @Eric
    I haven't tried new sample app to verify. But anyway, I had the problem when I used SDK directly. Have you modified SDK to fix the problem?
  • It is fixed in the latest API release, v1.6.0
  • Thank you igor_filippov for helping us fix a bug!
This discussion has been closed.