ADC Conversion jamming on noisy signals.

ManuSisko · Joined: 17 Jul 2018 Posts: 5

Hello. I've constructed a PCB for amplification and filtering from a Photopletysmograph. Basically, a Transimpedance Amp, a 1.5 kHz Band Pass Filter, an IRed Led Modulated at 1.5 kHz and a Photodiode.
I use the PIC 18f2550 to sample the signal, pack the samples and sending it to PC via USB comm. I'm using a 20 MHz crystal with PLL/5 for USB so FOsc = 48 MHz.

Everything seems to work perfectly, but I've got a problem. When the signal from the PPG, (which I take from the output of the BandPass Filter + Inverting OpAmp) gets a little noisy, the ADC takes a really long time to convert it. Now this delay is not noticeable, but it triggers a loop that crashes my device.

Here's how the sequence goes:
1. I use Timer 0 to modulate the Infra Red led at 1.5kHz. Timer0 triggers an interrupt with a 6 kHz frequency. ( Turn on Led -> Sample signal -> Turn Off Led -> Sample Signal -> ...) This ensures that the sampling is sync'ed with the modulation.
2. Timer0 also packs the readings (in my code I read a second signal from another channel but I've disabled it while I fix this problem), for the USB buffer.
3. I have a Qt App in my PC that receives the data, plots the signal, and shows how many samples were received in the last second (i.e. the interruption frequency of T0).
4. Main code sends the packets when they are full and Timer1 handles commands from the PC.

I've configured my ADC like this, ensuring max frequency:
setup_adc(ADC_CLOCK_DIV_64|ADC_TAD_MUL_4);
setup_adc_ports(AN0_TO_AN9|VREF_VDD);
set_adc_channel(PhPin);

Suppose the signal gets a little noisy (abrupt peaks for example), then the Timer0 delays (the AD conversion "hangs" for some reason) to modulate the IR Led, the signal from the PPG is no longer modulated at 1.5kHz, thus the BandPass filter distorts the signal (removing components), and the signal becomes more noisy, resulting in a greater delay in the timer 0 interrupt, which leads to more noise, and so on. The only thing that could delay the T0 Interrupt is the AD Conversion.

When this happends, my PC App receives less and less packets down to a sampling frequency of 200 Hz (from 1470 under normal conditions). I have no clue why this "peaks" in the signal are causing the Timer0/ADC to delay. Any and all suggestions would be appreciated. Below is my code:
USB_main.h

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

The ADC only allows it's Vin, to go between it's reference voltages. In your case Vdd and an external Vref. The signal needs to be limited externally to this range. You need to think about your external amplifier design and how to ensure the signal never goes outside this range...
If the signal goes above Vref, the input stage gets reverse biased.

Separately, re-think your RTCC loop.
Currently you have huge delays for the ADC in this loop. Delays for Tacq, and then the actual conversion. Ouch. Especially considering how quickly this loop is called, re-think and sequence the operations. You have a partial state machine, turn it into a complete one. Turn off Tacq.
Then sequentially on the interrupts:
State 0 select an ADC channel
State 1 start an ADC conversion (don't read)
State 2 read the result
State 3 select next channel
etc. etc..
This way the conversion and acquisition is done in the background, between interrupts, not inside the interrupt.

As a general comment, you are wasting an instruction clearing the interrupts in the handlers. The compiler automatically clears interrupts unless you use the instruction 'NOCLEAR'.

Then as another general comment, this:

temtronic · Posted: Wed Jul 18, 2018 5:03 am

Just a comment about the hardware.

You should measure the IR sensor/filter-amp power supply. It needs to be decoupled and very stable. This holds true for the PIC VDD as well. ANY minor fluctuation in VDD can and will affect your project. As well ensure good (wide) traces for grounds and use lots of bypass caps.
Hopefully you have access to an oscilloscope so you can actually see the signals, a DMM typically samples at 3Hz, far too slow to see noise.

ManuSisko · Joined: 17 Jul 2018 Posts: 5

ManuSisko · Joined: 17 Jul 2018 Posts: 5

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

You wouldn't use current_packet at all.

memset(sendData, 0x00, 64);

You want to zero 64 bytes not 63. In C, the name of an array is the address of it's first element. So 'sendData' is equivalent to '&sendData[0]'.

ManuSisko · Joined: 17 Jul 2018 Posts: 5

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

You shouldn't need to test adc_done. So long as the delay between interrupts is longer than the slowest ADC operation. Smile

On the buffer yes you can start at the offset point, using &sendData[currentPacket], but in this case you would have to use:

memset(&sendData[currentPacket], 0x00, TX_SIZE-currentPacket);

Your existing code will be clearing bytes in memory beyond the end of the buffer. Think about it, you clear 64 locations, if you start anywhere beyond zero, you will be clearing things you shouldn't....

ManuSisko · Joined: 17 Jul 2018 Posts: 5

Yes I don't technically need to check, but as I haven't implemented the voltage clipper yet, I use it to prevent my PIC from hanging when the signal goes outside the range.

Yes I forgot to mention that change haha. I used:
memset(sendData[currentPacket], 0x00, 64 - currentPacket);

Thanks mate!

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

There is an interesting erratum on some PIC's, which results in the GO/DONE bit not correctly being set when the conversion completes. This is not listed for your PIC, but a couple of people have experienced it in 'random' circumstances, possibly relating to the nature of the input signal, on other PIC's. It sounds like this is what is happening to you.
One solution is to test the INT_AD bit rather than the GO/DONE bit to test for the end of conversion. The other is to not use the bit but just allow enough time. Doing the conversions using the longer times involved in your interrupt ought to fix this, if this is what is happening on your chip.