Hi there,
I used it in a demo for measurements, of averages less than a centimeter.
You may find it useful it worked well.
at first blush, I think Hmm, clothing could contribute a little, but it does not look like the main cause here.
The strongest clue is this:
- the reported rate is consistently about +4 bpm
- but your own FFT of the breath phase matches the metronome
That points more toward an algorithm / reported-rate calculation issue than a basic sensing problem. If the raw phase signal’s dominant frequency matches the true breathing pace, the radar is probably “seeing” the breathing rhythm correctly and the error is more likely happening in the module’s processed breath-rate output.
There’s also a pretty important clue in Seeed’s own MR60BHA2 wiki: for firmware v1.6.12, they explicitly say breathing and heart rate accuracy were not updated in that release, that continued optimization was underway, and that the previous breathing/heart-rate algorithm had fundamental issues that were being addressed. That makes firmware/algorithm behavior a much stronger suspect than anything like posture, position or clothing alone.
The MR60BHA2 is designed for breathing/heartbeat detection within about 1.5 m 
, with installation and alignment mattering for best results. Seeed’s setup guidance also stresses orientation and positioning toward the chest region. If that geometry is off, quality can degrade, but again, that usually shows up as weaker or jumpier detection rather than a neat fixed offset.
The datasheet says the module is intended to be robust to things like temperature, humidity, noise, airflow, dust, and light, and it can work through clothing/bedding in general use. So ordinary clothing is not the first thing I’d blame unless it’s especially loose, thick, or moving independently of the chest.
There is also at least one Seeed forum report from another user saying the MR60BHA2 readings were consistently higher than manual counting and a respiration belt, especially at lower breathing rates. That does not prove the exact same bug here, but it does support the idea that this is not an isolated observation. 
The module’s current respiration-rate algorithm / firmware interpretation IMO is probably the culprit. 
You may want to compare firmware versions if you can safely do that, especially older/newer ones around 1.6.10 / 1.6.12 after checking release notes carefully.
HTH
GL 
PJ 
This is a Fantastic area of TECH, stem sensors and MMwave tech.
It has limits:
- sensitive to noise / motion
- algorithms matter a lot (as you just saw with the +4 bpm issue)
- placement is critical
The hardware is powerful
The firmware makes or breaks it