analog sampling frequency

propan

I'm trying to figure out if I would be able to sample analog input at the frequency around 40-50 sps.

I've modified the Android Sample amp (latest available version) to increase the sampling frequency.

I have observed that even on the 20Hz I'm getting dropout values from ADC (as ADC value, not referenced). I have went to max and decreased the GPIO_SAMPLE_PERIOD to 1 (ms) and started to acquire periodic pattern in measurements - see attached image. My current work-around is to make a mean of those values to form a single measurement. As a result I'm getting the measurements with a mean period of 60 ms (16.4 Hz).

I'm curious if this 4-values sequence is related to the ADC going through conversion and I'm reading some intermediate values. Or is it related to BT transmission?

Offline logging of ADC data might also be an option.

API version is 2+

FW 1.0.4

HW revision 0.2

Eric

Doing 50 samples a second shouldn't be a problem.  I would check if doing offline logging results in the same behavior.

What values are you expecting to see from your sensor?

propan

Thanks, Eric.

I would expect to have around 500 + slow (1Hz) component. It is in fact PulseSensor. Have you observed such thing as well?

I've tried to do the logging, but somehow I was not able to read out the values. Accelerometer logging/download was working fine.

propan

@Eric,

I've used the updated API with download fix and was able to get 1 ms resolution data from logging.

There are dropouts there as well with periodicity of 39 measurements.

It looks like they are somehow correlated with the timing from log message timestamp.

I have set the GPIO_SAMPLE_PERIOD to 1 (ms), but the spacing of the measurements is not even (see data below). I can email you the data if it helps.

0.317,505.0

0.318,540.0

0.321,549.0

0.322,549.0

0.325,553.0

0.327,556.0

0.330,535.0

0.331,551.0

0.334,508.0

0.336,542.0

0.341,531.0 - step of 5 ms from previous point

0.343,479.0 - the dropout

0.344,529.0

0.347,529.0

0.349,544.0

0.352,510.0

0.353,508.0

0.356,549.0

0.358,555.0

0.361,559.0

0.363,530.0

0.365,557.0

0.368,523.0

0.371,555.0

Eric

Sampling at 1ms (1000Hz) is incredibly fast, faster than the logging time granularity, which is ~1.5ms.  There is also the delay from doing flash writes so that would also factor in to time offsets.  Do you even need to be sampling the pulse sensor that quickly?  When Laura coded the Heart Rate app (https://github.com/mbientlab/HeartRate), she used 50ms.

I tested 10ms sampling with a pressure sensor (https://www.adafruit.com/products/166) and nothing seemed out of the ordinary.

propan

@Eric

True, I do not need it to be that fast. 50Hz (20 ms) would be just fine. 

I'm trying to figure out where are those outliers are coming from (as shown on the original post).

Could you share your code / settings for the 10ms sampling?

Thank you in advance

Eric

I am not doing anything special, just changed GPIO_SAMPLE_PERIOD to 20ms.

propan

@Eric

As a brief update - I have tried the external ADC ADS1115 to measure the same singal and observed the same dropouts. I was only able to fix it by powering from external 3V source. I guess the voltage from a battery is going down periodically during bluetooth transactions (I'm streaming data from accelerometer in parallel) and this leads to drop in LED intensity and measured signal.

Would you be able to suggest some solution to stabilise the power to have a constant 3V supply. My current battery is the default 100mAh that you've provided.

Eric

You can try using a bigger battery, such as a 200mAh battery. However, running two sensors in addition to the LED draws a huge amount of current, possibly more than the lithium battery can provide.

Matt

@propan

We have experienced similar disturbances with the ADC and the On-die temperature sensor from droop on the 3V supply caused by current spikes during radio events.  The radio bursts up to 10-15mA depending on TX power settings.  We believed the droop to be localized to supplies internal to the chip, but if you are seeing similar behavior with an external ADC, then that scope of the problem may have grown.

We will do some testing to quantify this disturbance system wide.

One solution we are considering for the ADC module, is to block and/or discard samples taken while the radio is active, restarting or resuming after the radio is complete.  This of course would not require any action from you other than a firmware update once available.

Regarding the 5ms dropout seen in your log data -- the worst case latency for the BLE stack on Rev2 silicon matches with this number.  If there is a BLE connection interval with enough events it can lock out other operations for a period of this duration.  Rev3 silicon reduces the worst case latency for interrupts to 250us, however few devices in the field have this revision -- and taking advantage of this would require some changes to our ADC implementation.  In the future, it might be possible to have an ADC endpoint for higher frequency sampling that is interrupt based instead of MetaWear event based.

Stay tuned.

Laura

@propan,

Here is some data from our projects that you might like to take a look at.

As Matt mentioned we generally discard or "smooth out" the data gathered during the BLE transmissions:

propan

Thanks for an update, @laura ;and @matt

@laura ;

I have a relatively low signal which is not oversampled, thus I can not simply filter out the dropouts with median filtering. My approach was to catch the frequency of the BT activity and remove it, but it does not seem to be stable in a long term.

I've also tried with 2.2Wh battery, which didn't help.

Anyway, my current overkill solution is to power measurement module with a dedicated battery and have a I2C connection with metawear, which works very very well if one discards the annoyance of charging two batteries.

I'm thinking about another solution, which is to have some reference signal (e.g. voltage level) connected to the second analog input and measure it simultaneously. I have not checked if it is possible with Metawear, but should be possible with ADS module. I can then discard or compensate the measurements during TX.

What do you think, would it be possible?

Matt

@propan

Regarding BT activity frequency: There are a couple variables in play, primarily the advertising interval and connection interval.  Change in connection state will transition between two different frequencies.  Overall radio traffic will affect the magnitude of disturbance in an event.  Re-connection cycles will cause breaks or offsets in the otherwise periodic disturbances.

Depending on your application, you may be able to take advantage of the device mode where advertising is turned off until an event restarts it, logging your data while offline.

Here is a snapshot of 3V supply disruption from radio traffic, taken on MetaWearRG:

The disturbance has very low coupling back to the battery.  So the issue is in the response time of the 3V voltage regulator.  In these instances there is a very large current impulse -- 10uA standby to 15mA radio event in a very short period of time.  The voltage regulator in use has been optimized for low standby current, which is a detriment to fast response times.  The magnitude of disturbance is in line with the datasheet specs:

Depending on how power sensitive your application is, it may help to add a static current load of 100uA to 1mA using a resistor and a GPIO pin.

Having a second battery would definitely isolate the noise as you have seen.  Considering that there is little disturbance seen at the battery anyway, the best case for a clean signal would be to have dedicated regulator for the analog circuits -- this is very common if not mandatory in precision analog applications.

I have a prototype firmware feature to reject and retry ADC measurements when the radio is active.  In practice it significantly reduces the magnitude of noise seen, especially for supply ratio measurements.  See below:

The blue resistive load does not experience much disturbance, this is because it responds very quickly to the supply variations, and so its output tracks the disturbance.  It has good common mode noise rejection.

The orange line has capacitance added, so any disturbance in its signal takes longer to decay.

The yellow and gray cases are equivalent to orange, but with the firmware ADC retry feature.  The magnitude of disturbance in those cases is bounded by +/- 1 ADC count.

In conclusion, this feature works quite well for signals which track the supply linearly.

For signals measured against the internal voltage reference, the supply noise should not be a problem if the supply is not used as a reference for the sensor -- if it is the signal should probably be measured against the supply.  Think sensors with an absolute voltage output, not a supply ratio.

Regarding compensating the ADC during TX, that could be a viable strategy.  I have applied that technique successfully in a project before to work around ADC limitations.

However, it should not be necessary if the signal linearly tracks the supply or has a stable absolute voltage output.  If the sensor is not properly designed to behave one way or the other, there may be a problem. e.g. The photodiode in something like the pulse sensor provides an absolute voltage output, but if the LED light source is driven with series resistor instead of a current source it will not reject supply variations well.  Though there could still be options to work around in that case, such as powering the sensor from the battery instead of the 3V supply.

The ADC retry will be a standard feature in the upcoming firmware release r1.1.0.

In the future, maybe we could have a "low noise" ADC measurement endpoint, where the firmware makes sure the measurement is taken at least a couple milliseconds after any radio event.  Of course, this would limit data rate considerably.