RC filter vs ADC sample time

[rusefillc]

@xtitoris says that input RC is too large for current ADC sample time

[rusefillc]

scope confirms left and right channels to be the same input signal yet firmware reads differently

[xtitoris]

Jumped a gun a little bit on the RC filter theory.
Firmware does read differently, but the root cause are transient effects of ESR injection.
b68ef03#diff-02aeb4da99beeaeac1eac3b31d16c1bdd0d80d8f25f136d6786d3521b1f044b1R48
Introduction of async ADC changed the order of operations to fire as soon as the ESR driver is toggled - messing up the first sample of adc conversion big way, skewing it enough that even oversampling does not help.
On the Dual board this is visible because first channel reads during the transient, messing up the data, while second channel reads after that, when transient has already finished.

There must be at least 30us delay between the ESR drive toggle and start of ADC acquisition.

Options:
For dual board the fix is relatively simple - reorder the ADC to start reading the channel unaffected by switching noises first, so that by the time main channels are read transients are already finished.
xtitoris@4711d95

For single boards (and the module) it is a bit harder

• either roll back the order of operations, so that we do the calculations before starting the ADC. (the comment is still there, even though it is not true anymore)
• add explicit delay of 30us after the toggle before starting ADC.
• add a timer that would asynchronously fire the ADC 30us after the request

On f0 module there are only 3 ADC channels, and full conversion should take around 300us (just ballparking there).
Pump control works at 500Hz, so 2ms.
There is no real benefit of sampling that much faster than the control loop - we can definitely spare 30us on each ADC run.

Unfortunately I only have dual hardware, so can't put a scope on a f0 module to test it properly.

[dron0gus]

Another one solution/hack - simply drop first sample when averaging.

Simply swapping these two lines does not solve the issue?

wideband/firmware/sampling_thread.cpp

Lines 48 to 51 in 7ccfdd8

	AnalogSampleStart();
	// Toggle the pin after sampling so that any switching noise occurs while we're doing our math instead of when sampling
	ToggleESRDriver(GetSensorType());

[xtitoris]

Yes, dropping couple of samples from the beginning would also do the trick.
We just need to figure out how many samples to drop - especially on f0 - would 1 be enough or would we need 2.
And also we'd need a big comment, describing why we are doing it.

Swapping those lines would solve the issue, but this solution will not be robust - based on the speed of the remaining code in the loop, it may or may not execute faster than required 30us. Some later refactoring would re-introduce the issue, in the same way this change to async ADC broke sampling, even though the delay intent was there from the beginning (and even having the comment there did not help)

The main idea here is to have measuring loop running at around 1-2kHz. And that means that using async ADC makes a lot of sense, as there's quite a bit of floating point math in the main loop, that slows it down significantly (especially on f0 without FPU).

I think the best solution here would be

• Use some kind of stable delay, be it a timer, or dropping first couple of samples, to avoid transient pollution.
• Use integer math instead of fp, to speed the measurement loop up even more.