I was using a chip AXI-060 (PSoC 5 architecture I think) before and was getting readings from some analog sensors (pressure transducers). Those readings were pretty accurate. I am now working with a 5 LP-032 chip, and I just notice that, even if I'm using the same code as on the AXI-060, those readings are completely different. I get a reading in mV that is about 3 times less than what I was getting with the old chip.
This is pretty scary. Any idea of what would cause that? Is the ADC different in PSoC 5 and PSoC 5LP?
What boards are you using? How do the projects differ apart from the code itself? Maybe the inputs are configured differently...
(The ADC should be comparable in performance, and if there are differences the 5LP should perform better than the 5)
Care to share / upload both projects?
Hi hli, and thanks for your help.
I'm uploading the 2 projects. I just used my old project, the one I was using with a PSoC5 chip (on PSoC Creator 2.2), copied it to create the same project with a PSoC 5LP chip (on PSoC Creator 3.0). Some components were updated automatically, like the AMux, ADC and I added "-u _printf_float" in the Linker so that I can display the float values. I tried them both, and there are still a *3 difference between what I get with the 2 chips/boards.
I am using some boards that were designed by a startup company. The only thing they updated is the chip, at least I think.
Would it be possible that some settings in the updated components changed something?
Another thing, on the PSoC 5LP project, I get the warning: "Warning-1366: Setup time violation found in a path from clock ( emFile_1_Clock_1 ) to clock ( emFile_1_Clock_1 )." Could it cause my issue?
This project's lsb is 2 uV, 128 mV total range.
Are you seeing a few counts or mV difference ? If latter then there is a problem.
If you look at pk-pk noise on Vdd do you see something like 200 mV of noise.
My point here is system noise is a big challenge. Did 5LP_ board change the
type of caps used for bypass ? One vendor to another can make a big difference
in ESR performance. Use polymer tants for best in class bulk bypass, and MLC for
hi freq noise.
Some applicable board layout apps -
Hi Dana, to answer you quickly for now, I'm getting 11mV on the PSoC 5LP project while I'm getting 32mV on the PSoC5 one. My output should be in the -35 to 35mV range. After comparing the 2 projects/board, I get a difference of about */2.8 to be exact.
The Vref on PSOC 5 was +/- 1%, whereas the 5LP is +/- .1%, an order
of magnitude better. Just a thought.
1. Does that problem happen on all 4 channels? or just one channel
2. Do you have a digital mV meter/CRO to measure the voltage, that should confirm whether the problem is the old one or the new one.
I also noticed that you are using the continous mode of the ADC which has a latency of 3 conversions, and this is mode is not recommended for multiplexed input.
How about use other mode and start the conversion of each input by software. Not sure if this can help.
Or to check if this is the source of the problem. Try change the delay for 3 times longer or do conversion 3 times each sensor and use the last reading.
I too guess the continous mode is the culprit here. The datasheets explicitely states its not suited when switching between signals. Use the multi-sample-mode, and stop/start the conversion between readings.
You also might want to add a bypassing cap for your Vref. This will reduce the noise, since your input voltages are rather small.
He is delaying for 100 mS after each mux change, sampling at 10KSPS,
continuous mode should not be the issue.
Wasn't there some buffers to be emptied when using continous mode instead of sigle conversions? Something rings in my mind, but I may confuse it with infos from a PSoC1
Found it in the datasheet under the explanation of the modes:
-Continous: Do not use this mode when multiplexing,
No mentioning of a delay might help, instead there are internal filters mentioned, so better stick to datasheet and use a different mode.
Even though the wait is about 1000 samples, I would not second-guess the datashett on that issue. Or do you know the DelSig-ADC so intimately that you know how many samples it takes to flush out old values from the decimator (the DS states that the continuous mode is the only one not flushing the decimator after each sample)?
@Bob, no there are some mentioning abouth that in the PSoC3/5 DS too.
In this case his delay equates to 1000 samples. I do not know
how many samples decimator takes to do a flush, per previous
If I have a mux, feed Vx to the ADC in continuous mode, and never
change the mux, is that a direct route to the ADC, and should it not
then convert with a small initial latency ? Or is the ADC intelligent
and discriminate against a direct route thru a mux ? We all know
what this answer is.
Now I change that mux, and I wait until the sun rises, is the ADC intelligent
and knows it has a scary mux input ? No, I do not think so. I would posit the
datasheet is warning user, in a incomplete fashion, trhat one has to take
care of settling issues or muxing at sampling rate.
Lets file a CASE and clear this up for all.
Thanks for all you inputs.
H L, the issue happens on all 4 channels. I know for sure that I get a correct (or about) result with the PSoC5 because I used another datalogger that gives me a similar result. I also used another device which gives me a number in the 30s.
So, I changed the mode to Multi sample, set a delay 3 times longer. No change.
I started the conversion at the beginning of my Pressure function, and stopped it at the end, so it starts and stops for each reading. No change. Still get a value of about 11 when it should be 3 times that.
I initialized my Pressure value to 0 in the function, before it takes the reading.
How do I add a bypass cap for Vref?
Could it be an issue with the clocks? They seem to be different clocks for the ADC in both projects.
Thanks Dana. I changed that setting, but I still get a value of 11mV.
I tried using the PSoC5 project on PSoC Creator 2, and changing only the device in Device Selector. The issue is there. I was wondering if that was because of the updated components in PSoC Creator 3, but it doesn't seem to be.
You used the adc_counts_toVolts(), the function may be affected by the gain and the offset variable used internally by PSOC, How about you try to do the calculation with the ADC reading yourself and see if the ADC output is also incorrect or just the result of the convert_to_volt() is incorrect?
You may also try to measure the offset of the ADC itself by shorting one pair of the input to see if that is too high as well.
The counts to volts APIs are affected by the below, which takes into account
Vref and all signal path gains, and is auto calced off the initial configuration.
You may modify this to take into account external signal path gains. So no
need to abandon use of the counts to volts function, unless you find a bug in it.
From tech support -
2) The decimator of PSoC3/5LP Delta-Sigma ADC consists of a 4-stage CIC filter. It can be considered as a pipe with 4 stages. In continuous mode of sampling, a sample result is available after every time "T", where "T" is the time taken by the input to propagate across 1 stage. After this,
This is described in the datasheet as "There is a latency of three conversion times before the first conversion result is available. This is the time required to prime the internal filter."
Hence when the input changes(/multiplexed), the first 3 samples would be invalid. The 4th sample should ideally be valid, provided the input was switched exactly at the same time of completion of previous sample.
But when multiplexing inputs, it is possible that the input might have changed(/multiplexed) half way during a conversion.
For even single stage ADCs such as integrating/incremental ADC, the first sample after changing(/multiplexing) the input should be ignored. So, for Delta Sigma ADC we should also skip the 4th sample after the input switching and take the 5th sample as valid.
1) Keeping the above information in mind, we would expect that delay of 1 mS in 10KSPS config - ie, skipping of about 10 samples, should work fine in continuous mode.
We will check regarding your additional question on the max clock rate and SPS, and update you.
Meanwhile, please let us know if the response on the first 2 questions is clear.
Thank you very much !
I noticed that several of you were unclear how many samples it takes to flush the decimator is the DelSig ADC. The answer is 4. That is why the sample rate between the Continuous and Multi-Sample mode is about a factor of 4. The Multi-Sample turbo mode is the same story up to 16 bits. Beyond 16 bits, the 2nd decimator, which is really just a filter, is being used to basically average several samples. The turbo mode becomes almost as fast as continuous time mode by the time you get to 20 bits, because it doesn't reset the decimator between the minor cycle or first decimator conversions. In a sense it is just averaging multiple readings from the continous mode. The overhead of loosing a couple conversion cycles becomes small when you are taking 1000s of readings.
As far as the real problem you are seeing, I'm not sure exactly what is going on here. The PSoC 5LP performance should always be better than the older PSoC 5 part. I assume you are using 20-bits and 16x ADC gain?
I cannot build your projects as with error "mmC_X_HW.h" is missing.
Another thing worth trying is to change both the amux and ADC in your 5LP project to the same version as that in your psoc5 project. See if that makes any difference.
H L, I got the same issue with "mmC_X_HW.h", and I solved it by setting again the emFile directories in the libraries. See the last reply on this topic: http://www.cypress.com/?app=forum&id=2492&rID=58867
I tried using the PSoC 5 project, and changing only the chip to the 5LP I am using, but the problem is there. Components versions were the same in both projects when I tried that.
What calculation should I make to get the result in mV (or V) from ADC_DelSig_1_GetResult32() ? Sorry, I'm still a beginner.
Regarding my last reply, something is different when I compile both projects. I get a warning in the 5LP one "Warning-1366: Setup time violation found in a path from clock ( emFile_1_Clock_1 ) to clock ( emFile_1_Clock_1 )."
I have a bad experience with warnings that were causing strange results. Anybody knows what is causing it and how to fix it? Maybe that could be the source of the issue?
Here's what the timing analysis says: see the pdf attached
The conversion functions are (in the datasheet) -
int32 ADC_CountsTo_uVolts(int32 adcCounts)
int16 ADC_CountsTo_mVolts(int32 adcCounts)
float32 ADC_CountsTo_Volts(int32 adcCounts)
Yes, I used the third one in my project but H L mentionned about doing the calculation with the ADC reading myself and see if I get the same result as what the function ADC_DelSig_1_CountsTo_Volts gives me. Did I misunderstand something? Please let me know.
1. I am assuming you have two PCBs,Do you use the same external circuit on the two PCBs?
2. Have/Can you measure the voltage at the pins of the 5LP?
3. What is the absolute values of the signal, ie reference to 0V.
4. Have you try using the SAR instead of the DelSig and see if the reading is still around 3 times lower, the SAR has lower resolution, but whould still can use as a reference
I think I fixed it! I "played" with the Input Range and when I set it to Vref/2 on PSoC5LP, I get some results that are much closer to what I get on the PSoC5 (Vref/16). Any idea on why it would be different?
It's not exactly the same results, at most 1mV difference, but it's much better. How would I know which settings would give me the most accurate results?
H L, I have 2 "motes" (one with a PSoC5 chip, and another one with PSoC5LP), and I use the same "board" (where I plug my sensors).
On PSoC5LP, I get a 0.031 to 0.032 voltage on the pins. That's what I get on the PSoC5. Now that I changed the input range, I get 32-33mV on the PSoC5LP, which is much better than 11mV! My sensors are pressure transducers so I tested at different pressure, and the results are more correct now.