Ah, I understand.
I'm not that familiar with the preprocessor directives, I'm going to have to read about them a bit. I've only seen them used to include header files and whatnot.
I wish I had gone to computer science school or something, it's a steep learning curve when you are trying to learn by your self reading stuff online.
BTW I tried the 12 bit one but it's giving me really high numbers, how can I convert it to show me 0-1023?
Well I've tried some low pass RC filters and it's still not that great but slightly improved.
Strange thing is when I use averaging of 2 I get worse results with the RC filters.
Maybe my expectations are too high.
Here is a screenshot capturing the noise, top pic is regular analog read.
Middle is ADC library with 10 bit and averaging of 1.
The lowest one is 10 bit averaging of 1 and low pass filters.
It's fine I guess but the analog read version was much better.
What bothers me are the high spikes that shoot up 4 values.
Oh and I'm only reading 2 sensors here so it's actually sampling at a very high speed per sensor.
https://www.dropbox.com/s/3p7bmigvqvokcsn/filter.heic?dl=0
BTW I tried the 12 bit one but it's giving me really high numbers, how can I convert it to show me 0-1023?
Nevermind, I was doing 1023 - sensorValue to give me an inverted signal, didn't work with a 12 bit value because it's a bigger number.
Indeed - need to account for the extra bits. 12 bit Conversion takes a tad longer so ideally the 10th bit less jumpy with right shift of 2 or divided by 4. Then treat the same as the 10 bit samples.
Are those 1000 samples of sensor at rest or under a constant pressure? Going to avg of 2 on read really adds time (posted code will show that in clock cycles with change in setup) - which is okay if results are better and that time can be put to use.
That is just with everything connected and at rest.
Only way for it to not jump up and down 4-5 values is to use averaging of 2. Conversion speed/sampling speed doesn't seem to affect it for the better. I don't know, maybe reading that many sensors this fast isn't plausible.
I got it working great with the regular analog read but this seems too erratic.
Again if you look at I think posting 51, the example code I did showed the different settings for analogRead() and how long it took to do so many of them...Looks like AnalogRead() normally uses averaging of 4 samples. Not sure about other settings.
Not sure what you expect, one or even a few bits of noise isn't bad.
But I see nothing that indicates the equivalent pedvide _SPEED library settings for the defaults of AnalogRead().
Wish there were one or more of your sensors set up here so I could see. Never looked this close at it before - and only from the code end. Not sure of the effect on the reading with the fast transition from one input to another reading both at once. Certainly no reason for that to improve the readings. It is a high speed digital processor, not optimized for analog fidelity.
The upper old FOR loop could be modified easily to read them one at a time to compare the results, or even changed to use analogRead.
I wonder what it does if both are read for a single sample - avg(1), discarded, then both read again - repeating for all 10.
Having the read at 12 bits then /4 to get 10 bits should get rid of noise in the last bits, unless it is really bad. Not sure of the effect of the capacitor feeding the onchip measuring device - though at steady state that should not have jitter.
Looks like AnalogRead() normally uses averaging of 4 samples. Not sure about other settings.
Not sure what you expect, one or even a few bits of noise isn't bad.
Again if you look at I think posting 51, the example code I did showed the different settings for analogRead() and how long it took to do so many of them...
https://forum.pjrc.com/threads/6156...d-of-execution?p=244780&viewfull=1#post244780
Wish there were one or more of your sensors set up here so I could see. Never looked this close at it before - and only from the code end. Not sure of the effect on the reading with the fast transition from one input to another reading both at once. Certainly no reason for that to improve the readings. It is a high speed digital processor, not optimized for analog fidelity.
The upper old FOR loop could be modified easily to read them one at a time to compare the results, or even changed to use analogRead.
But I see nothing that indicates the equivalent pedvide _SPEED library settings for the defaults of AnalogRead().
void analogReadRes(unsigned int bits)
{
uint32_t tmp32, mode;
if (bits == 8) {
// 8 bit conversion (17 clocks) plus 8 clocks for input settling
mode = ADC_CFG_MODE(0) | ADC_CFG_ADSTS(3);
} else if (bits == 10) {
// 10 bit conversion (17 clocks) plus 20 clocks for input settling
mode = ADC_CFG_MODE(1) | ADC_CFG_ADSTS(2) | ADC_CFG_ADLSMP;
} else {
// 12 bit conversion (25 clocks) plus 24 clocks for input settling
mode = ADC_CFG_MODE(2) | ADC_CFG_ADSTS(3) | ADC_CFG_ADLSMP;
}
tmp32 = (ADC1_CFG & (0xFFFFFC00));
tmp32 |= (ADC1_CFG & (0x03)); // ADICLK
tmp32 |= (ADC1_CFG & (0xE0)); // ADIV & ADLPC
tmp32 |= mode;
ADC1_CFG = tmp32;
tmp32 = (ADC2_CFG & (0xFFFFFC00));
tmp32 |= (ADC2_CFG & (0x03)); // ADICLK
tmp32 |= (ADC2_CFG & (0xE0)); // ADIV & ADLPC
tmp32 |= mode;
ADC2_CFG = tmp32;
}
Defines the sample time duration. This has two modes, short and long. When long sample time is selected
(ADLSMP=1) this works for long sample time otherwise this works for short sample. This allows higher
impedance inputs to be accurately sampled or to maximize conversion speed for lower impedance inputs.
Longer sample times can also be used to lower overall power consumption when continuous conversions
are enabled if high conversion rates are not required.
00 Sample period (ADC clocks) = 2 if ADLSMP=0b
Sample period (ADC clocks) = 12 if ADLSMP=1b
01
Sample period (ADC clocks) = 4 if ADLSMP=0b
Sample period (ADC clocks) = 16 if ADLSMP=1b
10
Sample period (ADC clocks) = 6 if ADLSMP=0b
Sample period (ADC clocks) = 20 if ADLSMP=1b
11
Sample period (ADC clocks) = 8 if ADLSMP=0b
Sample period (ADC clocks) = 24 if ADLSMP=1b
The last code I have here was asking for 12 bit ADC reads - with 1 avg - not sure if that gives a more stable 10 bit value? It takes longer - but with the dual read improvement it offset the longer read time.
Here is the code I have last edited - there is an #ifdef for loop versus unrolled with cycle count around the two methods.
YMMV - not sure what I poked at last - but here it is - don't forget to call errCkADC() during debug to test that pin order in array works with the ADC it gets assigned to - perhaps in the 1 second update "if ( lT >= 1000 ) {":
#else
{
#define someWork //{ delayNanoseconds(50);}
uint32_t ii=0;
adc->startSynchronizedSingleRead(A10, A2);
while (adc->adc0->isConverting() || adc->adc1->isConverting());
lastR[ii++] = adc->adc0->readSingle();
lastR[ii++] = adc->adc1->readSingle();
adc->startSynchronizedSingleRead(A11, A4);
someWork
while (adc->adc0->isConverting() || adc->adc1->isConverting());
lastR[ii++] = adc->adc0->readSingle();
lastR[ii++] = adc->adc1->readSingle();
adc->startSynchronizedSingleRead(A5, A6);
someWork
while (adc->adc0->isConverting() || adc->adc1->isConverting());
lastR[ii++] = adc->adc0->readSingle();
lastR[ii++] = adc->adc1->readSingle();
adc->startSynchronizedSingleRead(A7, A8);
someWork
while (adc->adc0->isConverting() || adc->adc1->isConverting());
lastR[ii++] = adc->adc0->readSingle();
lastR[ii++] = adc->adc1->readSingle();
adc->startSynchronizedSingleRead(A9, A0);
someWork
while (adc->adc0->isConverting() || adc->adc1->isConverting());
lastR[ii++] = adc->adc0->readSingle();
lastR[ii++] = adc->adc1->readSingle();
}
#endif
while (adc->adc0->isConverting() || adc->adc1->isConverting());
lastR[ii++] = adc->adc0->readSingle();
lastR[ii++] = adc->adc1->readSingle();