Issues in BatchSampler

[andyp1per]

Bug Summary

There are some problems in the BatchSampler which will cause samples to get dropped - and thus frequency analysis to be incorrect - and can cause free memory reads

Issue details

• BAT_LGCT cannot possibly be correct as a configuration option. The size is hardcoded to 32 in the logging output and also the buffer size is scaled to a multiple of 32. Setting it to anything greater than 32 will caused free memory reads in the logging code. I have removed this.
• data_write_offset is written and read from different threads but there is no concurrency control. I have made this volatile to try and mitigate, but really there should be locking around the access.
• we drop loads of samples while cycling between sensors. this is really bad as it means that the stream of samples is not really a stream of samples but a sub-sampled set of frames. individual frames are correct but meaningless when treated together

EDIT: upon further inspection it seems the batch sampler is designed to leave holes in the sampled sections. If we push 32 samples every 20ms that equates to 1600 samples per second total, which for 4 sensors (say) equates to 400 samples a second. But this is far below the backend sample rate of 1Khz and is effectively another sample rate that will give you weirdness in the FFT (which is what I am seeing). What you really want to do is either (a) sample at the full rate 1Khz x 3 axes x 4 sensors x16bit = 24kB/s which should be fine on modern SD cards or (b) uniformly down-sample rather than simply dropping whole sections of samples. EDIT: it's even worse than this because we drop samples when cycling between sensors

Fixed in #12349

Version master

Platform [ X ] All [ ] AntennaTracker [ ] Copter [ ] Plane [ ] Rover [ ] Submarine

Airframe type N/A

Hardware type N/A

Logs

[IamPete1]

@andyp1per Any updates?

[andyp1per]

@IamPete1 I need to pick apart my PR to separate these bits. A long way down my priority list.