EVOLV data structure about omblepy HOT 4 OPEN

Hi Güsel,

if I remember correctely, vulcainman investigated the decoding and came up with following data structure:

• "mov" for movement detection
• "ihb" for irregular heart beat

If you have additional information about the error readout or the other parts of the data stream for the device, please let me know. A second crosscheck of the current data structure is also helpful.
I don't own the hem7600, so I unfortunatelly can't do any testing.

Best,
Benjamin

from omblepy.

Hello Benjamin, I compared the structure. What I can add based on my research is information about cuff fit. If the cuff position is recognized as incorrect, bit 51 = 0. Bit position 62 generally signals that a problem with the cuff or movement has been detected. According to my observations, bit 63 is set when the battery is "empty". Bits 64 - 71 are an arrhythmia counter. According to my observation, the Omron app shows the arrhythmia starting from a value of 11. Movement or poor cuff fit also start the counter.
What else you can set are the dates of birth, to what extent these influence the measurement process or alarm signals is not clear.
Otherwise there are the checksums within the sentences and the XOR at the end of the sentence, but this is apparently already checked in the driver.
My HEM7600 is one of the first devices, so there might be differences in the structure.
I implemented a solution for the HEM7600 on an ESP32 in C++/C with WLAN and DB connection. This has been running smoothly for 3 years. I would like to try the Python application.
Greetings Güsel

from omblepy.

So if I read your last post correctly that would be:

recordDict["cuf"]      = self._bytearrayBitsToInt(singleRecordAsByteArray, 62, 62) 
recordDict["bat"]      = self._bytearrayBitsToInt(singleRecordAsByteArray, 63, 63) 
recordDict["arc"]      = self._bytearrayBitsToInt(singleRecordAsByteArray, 64, 71) 

It's a bit strange that the battery and cuff flag would overlap with the seconds counter.
But maybe that could also be bit counting convention, since I use endian dependent byte order and process the complete record as one huge number

Otherwise there are the checksums within the sentences and the XOR at the end of the sentence, but this is apparently already checked in the driver.

I assumed these to be part of the protocol, since the xor sequence is present for all messages, not just the transfered records.

I implemented a solution for the HEM7600 on an ESP32 in C++/C with WLAN and DB connection. This has been running smoothly for 3 years. I would like to try the Python application.

For the best experience I would recommend testing with Windows first, since the linux bluetooth stack seems to be buggy for Bluetooth LE devices in some versions. The great thing with your ESP32 solution is, that you can circumvent all bluetooth driver issues 😄 .

Best,
Benjamin

from omblepy.

Hi Güsel,
your solution sounds very interesting!
Do you have any plans to release the code on GitHub?

from omblepy.