- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm having a problem while trying to sample some signals when using an AMUX, a PGA and the SAR ADC.
I need to sample many light sensors that can receive light from various groups of LEDs.
The LEDs are controlled by PWM in the same PSoC. Only one LED is on at a time. To multiplex the PWM I'm using AND gates conected to the PWM output and to a control register. I've also tried using a demultiplexer.
Anyway, the problem is happens when I do this:
PWM_Out_Reg_Write(LEDPowerOrder[selectedLED]); //Select PWM output pin.
PWM_LED_WriteCompare(10); //Configure LED power
AMux_1_FastSelect(0); //Select sensor input
PGA_1_SetGain(1); //Set PGA gain
ADC_SAR_1_StartConvert();
ADC_SAR_1_IsEndConversion(ADC_SAR_1_WAIT_FOR_RESULT);
sample = ADC_SAR_1_GetResult16();
PWM_Out_Reg_Write(LEDPowerOrder[selectedLED]); //Select second LED output
PWM_LED_WriteCompare(0); // Turn it off.
AMux_1_FastSelect(1); //Select second sensor
PGA_1_SetGain(1); //Set the gain of the PGA
ADC_SAR_1_StartConvert();
ADC_SAR_1_IsEndConversion(ADC_SAR_1_WAIT_FOR_RESULT);
sample2 = ADC_SAR_1_GetResult16();
Well after that, I graph both samples and the second sample still gets part of the signal of the first sample but with less amplitude even when I've turned off the LED. I also tried not using the PWM and just using the pin ON OFF directly and I get the same results. The sensor is fast enough to keep up with the LED and I have no capacitors in the ADC inputs.
So, I would like to ask what could be causing this or if I'm doing something wrong or missing something, since this is my first project with PSoC 5.
How much time should I wait for the signal to settle between multiplexor selections?
I have the PGA configured to high speed and the datasheets says that it has 7pF of input capacitance. The ADC is running at 100000 sps.
Thanks in advance!
- Labels:
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When you provide us with the complete project we might check your settings, too. To do so: In Creator choose "File->Create Workspace Bundle (minimal)" and upload the resulting file here. Do not use Chrome, it has got errors when uploading files.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I do not see where you have allowed any settling time for AMUX
swicthing.
Also if you are changing PGA gain and that results in a large signal step
you have to consider its slew rate perormance. If not a large signal step
then you have SS settling time to consider.
Regards, Dana.
From AMUX datasheet -
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is P/N of light sensor ? That also may have a turnoff settling time,
especially if a minority carrier affected sensor ?
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A couple of other considerations -
1) You are switching, potentially, a lot of LED current, that means ground bounce,
transients, noise. Use polymer tantalums to get bulk bypass performance an order
of magnitude better than regular Ta caps.
2) Bypass the ref supply on PSOC.
3) The slew rate and SS performace on PGA is not just a gain change problem,
it exists for any situtation. You might try out a test on AMUX - PGA signal path with
a simple step forcing function and examine with a scope, looking for latency and
settling time to 1/2 LSB (or your criteria) of the SAR.
4) Examine in depth light sensor response. You could include that in signal path
check ( 3) above) and stimulate signal chain measurments with LED step in its
output.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dana,
Thanl you for yout advices.
The sensor I'm using is a TSL257. In the datasshet they specify a rise time of less than 100nS but the fall time doesn't seem to be there. I've checked with the oscilloscope and I get a response way worse in fall times for a light pulse so the problem is probably that.
Anyway, I will try to test the response of the PGA with a step with my configuration to make sure there is no problem there. I will add the settling time for the AMUX. Noise doesn't seem to be a problem because we already follow the bypassed recommendations.
Thank you for your help. If I find anything that is not working ok after checking the PGA with the AMUX I will post it here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Sorry to bother again. I've tested the ADC with the PGA and the problem was as expected the sensor.
Now I have another problem that has happened before and I don't understand why.
I have the function that samples all sensors and updates the duty cycle of the LEDs which is called every 100ms. It is called by a timer that enables a flag which is checked in the main loop. I've measured the time it takes to complete the function using an output and the oscilloscope. I set the output high before entenring the function and set it low after leaving the function. I measure always 25ms If I don't change anyhthing.
Then, using a PC I send through the UART a command to update the array that holds the duty cycle of each LED for the PWM. The problem is that when I change three or more of those duty cycles the function gets "stuck" and instead of 25 ms it goes over 100ms and then the timer interrupt is thrown and since the function hasn't finished the flag is not set.
If I only change a couple of duty cycles it works just fine (25ms). You can see in my proyect that I only have one PWM module and I update the compare value before choosing the output of the PWM.
If I comment the WriteCompare function of the PWM inside my loop it works fine but I can't find which can be the cause of the "lag" introduced when I the writeCoompare function writes different values than 0 for more than 2 LEDs.
I've tried 20Mhz, 10Mhz, 3 Mhz, 1Mhz but it doesn't seem to make any difference.
My Bus Clock is 62.4 Mhz. The details are the same as the project posted earlier.
Does anyone have any Idea of what coud be causing this?
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When updating the array via UART I would synch that operation with end of PWM period,
and stop PWM, do the update, then restart PWM. I am thinking that by changing
asych the PWM duty cycle you will get expanded ISR behaviour as you are seeing.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dana,
My sampling routine (which also updates the LEDs duty cycle) is executed when the flag in the main loop is set. When I receive an update PWM packet, it is not processed until the sampling routine is done, since the processPacketFlag is also in the main loop.
Right noww I have the sampling routine like this:
for (selectedLED =0; selectedLED<MAX_LEDS; selectedLED++){
PWM_LED_WriteCompare(LEDPowerValue[selectedLED]);
PWM_LED_Start();
CyDelay(1); //wait for sensor to settle
for (selectedSensor =0; selectedSensor<MAX_SENSORS; selectedSensor++){
//Select Amux input and wait 5us to settle
//Sample with ADC
}
PWM_LED_Stop();
}
It doesn't matter if Update it through the UART or not. If I just hardcode the power of at least 3 LEDs to 10 (I have a period of 16) It won't meet the 25ms from the beginning.
I've also seem that if I start changin the LED's power the speed I'm receiving the data starts to decrease. I should get 10Hz but If I increase the power of 1 LED by one it goes to 9,96 then if I change another I get 9,6 and then with the third or more it just start droping samples and goes to 6hz or so.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I think I've found the problem. It seem it has nothing to do with the PSoC but with the hardware. If measure the noise of the power rails of the PSoC right at its supply pins I get about 50mV of noise. But I've measured the ADC inputs and I measure almost 400mV over the 3.3 Analog supply when the LEDs are switching... This is because there is a cable that connects to another PCB where the LEDs and sensors are, and in that PCB, they share ground and supply, so even when our PCB has separeted analog and digital grounds both sensors and LEDs share their ground and 3.3V which is supplied by our board.
If I disconnect the LEDs and sensor boards the program runs as expected.
Thank you anyway for everything and sorry for the inconvenience.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A technique to get a handle on noise is to use a DSO in infinite persistance
mode and look at a supply rail. You will then get a "true" measurement of pk-pk
noise that is otherwise much more difficult with an analog scope.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thank you for the advice but I already did that and I get 50mV at the most when I measure supply rails in our board. I get noise only in the ADC inputs which signal comes from the other board and in the supply rails when I measure them in the other board since it is connected to ours by a 1 meter flat cable and power is comming from our board.
Thank you.