EVOLV data structure

[Guesel]

Hello Benjamin, I have completely decrypted the data sets for the 7600 Evolv. Information about the error bytes and the arrhythmia values are available. If you are interested please reply.
Kind regards, Güsel

[userx14]

Hi Güsel,

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

omblepy/deviceSpecific/hem-7600t.py

Lines 22 to 37 in 1f43fef

	def deviceSpecific_ParseRecordFormat(self, singleRecordAsByteArray):
	recordDict = dict()
	recordDict["dia"] = self._bytearrayBitsToInt(singleRecordAsByteArray, 0, 7)
	recordDict["sys"] = self._bytearrayBitsToInt(singleRecordAsByteArray, 8, 15) + 25
	year = self._bytearrayBitsToInt(singleRecordAsByteArray, 16, 23) + 2000
	recordDict["bpm"] = self._bytearrayBitsToInt(singleRecordAsByteArray, 24, 31)
	recordDict["mov"] = self._bytearrayBitsToInt(singleRecordAsByteArray, 32, 32)
	recordDict["ihb"] = self._bytearrayBitsToInt(singleRecordAsByteArray, 33, 33)
	month = self._bytearrayBitsToInt(singleRecordAsByteArray, 34, 37)
	day = self._bytearrayBitsToInt(singleRecordAsByteArray, 38, 42)
	hour = self._bytearrayBitsToInt(singleRecordAsByteArray, 43, 47)
	minute = self._bytearrayBitsToInt(singleRecordAsByteArray, 52, 57)
	second = self._bytearrayBitsToInt(singleRecordAsByteArray, 58, 63)
	second = min([second, 59]) #for some reason the second value can range up to 63
	recordDict["datetime"] = datetime.datetime(year, month, day, hour, minute, second)
	return recordDict

The only flags currently processed/known are:

• "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

[Guesel]

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

[userx14]

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

omblepy/sharedDriver.py

Lines 24 to 29 in 1f43fef

	def _bytearrayBitsToInt(self, bytesArray, firstValidBitIdx, lastvalidBitIdx):
	bigInt = int.from_bytes(bytesArray, self.deviceEndianess)
	numValidBits = (lastvalidBitIdx-firstValidBitIdx) + 1
	shiftedBits = (bigInt>>(len(bytesArray) * 8 - (lastvalidBitIdx + 1)))
	bitmask = (2**(numValidBits)-1)
	return shiftedBits & bitmask

so one needs to be extra cautious here. Also I need to think of a way to output the additional values, without breaking compatibility with the other devices lacking those bits.

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

[sbugert]

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