Logger mystery!!!

guy · Joined: 21 Oct 2005 Posts: 297

I have a data logger (2 channels) that takes several 10-bit samples from the built-in ADC, accumulates them in a 32-bit array (array to support both channels), calculates an average by dividing the result by the number of samples, then transmits the result.
I connected it to 2 different pressure sensors connected to the same pressurized system and measured the pressure which gradually falls over the weekend.
https://www.flickr.com/photos/14648393@N05/shares/0i1j7t
As you can see from the graph there are 3 glitches where the pressure on both channels seems to rise slightly. I am assuming that this is some kind of SW/HW bug since the pressure is not likely to behave like this.
There could be several reasons in HW and SW for this to happen (reference voltage, ADC non-linearity...) but here comes my question:
Could it be that the division of the 32-bit number by an 8/16 bit number will cause this effect???
The scale on the graph is floating point but this is created later in the process. I checked the integer result of the division and the glitches exist there already.
Another interesting clue is that the rise (glitch) appears in 2 consecutive rising values, not just one, for example
2.517
2.512
2.503
2.498
2.508
2.537
2.527
2.522
2.512

any other ideas welcome.
PIC16LF18855, CCS 5.074

Ttelmah · Joined: 11 Mar 2010 Posts: 19506

No. Division of a 32bit number by a 8/16 bit number is done using a 32bit divide. This is standard C.

Several possibilities:

1) You don't say how the output is synchronised to the sampling?. Is it possible that a value is being output before the sum is complete?.
2) You don't describe your arithmetic to convert the 32bit sum to the final result. Could this be having a step change at particular levels?.
3) Are you sure the sum and division are being being performed with the types as you describe?. You need to look carefully at internal parts of the maths. Any use of intermediate temporary variables?.
4) You talk about multiple channels. Are you sure the arithmetic at all points is talking to the right subscript?.
5) Also, how is the sensor read?. It could have the look of a synchronisation problem between the read and the averaging.

It has the look of something like perhaps every X samples something is out of sync, so a sample is read twice, the array is not cleared, the addition is done an extra time etc..

guy · Joined: 21 Oct 2005 Posts: 297

Good points Ttelmah:

guy · Joined: 21 Oct 2005 Posts: 297

ok, this is going into the HW area but any help would still be appreciated.
My circuit works on 3V and an MCP16251 boost regulator supplies 5V to the sensor. Both the 5V and the sensor signal are scaled down using resistors to 0-2V scale so that the 5V creates a 2V reference value (connected to Vref+) and the sensor signal is sampled using that ref. The sensor itself reacts to changes in the 5V supply although not linearly i.e. it does not have a built-in reference.
I've been sampling the lines for several hours and at some point I see the 5V supply going slightly down from 5.00V to 4.90V.
The slight drop in the supply didn't happen for hours, then appeared for just a few samples (a couple of minutes) and recovered.
At the moment I am working with 2x AA batteries as power source but the graph I sent was made using a lab power supply.
Any ideas what would affect the output of the regulator in such a way, assuming there is no significant change in environment, load, supply? Also theoretically the supply voltage should be cancelled out if the signal is ratiometric to the supply and the supply is used as reference, but the linearity of the sensor is not really guaranteed.
(edit)
Even a temporary change in supply doesn't explain the glitch+shift up of the graphs... I am lost...

temtronic · Posted: Sun Sep 10, 2017 5:17 am

Can't speak about the math but...

I notice that 'restart_wdt' is in your code. Have you tried without using the WDT ? At least try without, if it still 'glitches' then you KNOW it's not a WDT caused problem (well, hopefully..).

I'd dump out the raw data at every step....follow the bits, so to speak. Send all data to a PC, save to a CSV formatted file, then run Excel and see if there IS a pattern. Let it run for few hours, say overnight. It has to collect enough data to see the 'pattern', if there is one.

You control power to the sensors. By dumping the raw data, you can see if the powering up is the cause. Perhaps one sensor is faulty? Can you swap sensors, though the math you do might not show up which is bad...
again, a log of raw sensor data (ADC results) and EVERY interim calculation should show WHERE the bad number is coming from.

Jay

Ttelmah · Joined: 11 Mar 2010 Posts: 19506

Some comments:

Are you sure your ADC supports operation off a 2v reference?.
Most PIC's don't. The minimum ADC span for full accuracy is typically perhaps 2.5v. Won't give the spikes, but will degrade accuracy.
Check the PIC data sheet.

Now you switch ADC modes. If you are sampling AN3, then you are using the supply as the Vref. If you are changing channels like this, don't enable the other multiplexer inputs. So: