search

limengdu / Seeed-Studio-MR60BHA1-Sensor

MIT License
26 stars 16 forks source link

The issue of breathing/ heart rate data broadcasting #9

Closed 4444monkey closed 8 months ago

4444monkey commented 9 months ago

Hi there, I recently tried the 60GHz radar module (MR60BHA1), and just confronted a problem. I'm sure following the seeed-wiki tutorial to comply with the code via the Arduino platform. However, when I tested the example code, I found both the breathing and heart rate data broadcasting were not stable (see the attached pictures). The radar board still remains in the factory setting. I was wondering why the data was not stable. Could anyone resolve this issue or provide tips for me? That will be a huge help.

breathing data_losing breathing data_losing2

limengdu commented 9 months ago

Are you referring to the instability in Figure 1 or Figure 2?

4444monkey commented 9 months ago

Hi Limengdu, Fig 1 should be the regular one but it became unstable (Fig 2) when the radar ran for a while. You may see the signals from breathing and heart rate disappear with the human presence detection function still working. It does not make sense that the breathing and heart rate functions were still on but getting irregular signal outputs.

I'd tested the serial port commands. The human presence command did work by testing the switch on/ off but neither in the breathing and heart rate commands. As I entered the correct command per the user manual with the right checksum and it gave me the right response. Somehow the breathing and heart rate function did still not return their data timely. Just like Fig 2., the data was gone after running the radar for a while. How can I resolve this issue?

limengdu commented 9 months ago

As the current software upgrade of the radar is geared towards sleep monitoring application scenarios. Therefore, only when the radar detects that someone is "in bed" will it start reporting respiration and heart rate values. In order to ensure the accuracy of heart rate and respiration measurements, the software performs very stringent checks on the judgement of "entering the bed". Firstly, the radar needs to be installed accurately. The radar needs to be installed in the middle of the bed, 0.8 to 1.2 metres above the bed surface and tilted downwards at 45°. If it is only placed on the desktop, it is difficult to judge it as "in bed". In order for the accuracy of the results to be as good as our tests, we recommend that you use the radar in a real sleep scenario. However, considering the convenience of debugging needs of engineers, we have turned on a simple judgement interface by default. When the radar is about 0.9m~1.1m away from the person, and keep stationary for more than 10 seconds, the radar will judge the person's "in bed" status. This should be the situation you are in. As for why it's unstable, it's most likely caused by the movement or motion you've created.

4444monkey commented 9 months ago

Thanks for your clear explaination and it's certanly helpful. Let me try to clarify it again. ~Firstly, this radar is not suitable for the regular breathing/ heart rate real-time dection since an individula might not always be in the static mode , correct? ~The breathing/ heart rate detection function is only activated when an individual is in the static status based on factory algorithm computing, correct?
~In light of the issue I confronted above, the breathing/ heart rate dection was off even I remained low body movement as shown in pic2, and it was the ime point when I thought it should trigger the breathing/heart rate detection function but it didn't. In the begining, I assumed the radar should send all the raw data packets and the individual function information is extracted by the code. Another weird thing can also be found between the breathing and heart rate curves. Presumably, If the breathing dection is off, the heart rate function will be off accordingly. However, it does not correspond to the finding in pic2. That's why it has me confused. Probably, it might be the result of the firmware issue. I'll try to update it to see if it can resolve this issue.

limengdu commented 8 months ago

Due to technical limitations, we had to do this to ensure that the radar could accurately capture the micromovement patterns of the human chest cavity. For further explanation and assistance, please contact our technical support team. If you have questions about the code or feedback on bugs, you are welcome to raise a new issue again. thank you for your understanding and cooperation.