search

airikka / spo2cms50dplus

Downloads recorded data from a CMS50D+ and stores it in SpO2 format
GNU General Public License v2.0
8 stars 6 forks source link

Live data streaming #1

Open patrick-samy opened 7 years ago

patrick-samy commented 7 years ago

Hi there,

Thanks for the script, works great to pull recorded data from a CMS50D+ with the 4.6 firmware.

However, I can see you haven't implemented live data. Do you know if that feature has been removed in the new firmware?

Unfortunately, I don't have a windows machine to test and reverse the protocol. In past versions, the device would simply stream the values without the need to send a command.

gabeerion commented 6 years ago

I've noticed the same issue! This script is really helpful in getting recorded data; I'd also like to be able to get live values as they come in. I'm in the process of trying to brute-force a lot of magic byte sequences like the one used in this script to see if any of them cause live data to start coming in. If anyone has better ideas I'm glad to try them. EDIT - I've also tried running the live streaming software on my Windows machine; I've even recorded API calls as was done to build this repo but am not expert enough to know what to do with them.

PS thanks @airikka for creating this script for 4.6 firmware!

patrick-samy commented 6 years ago

@gabeerion I did reverse the 4.6 prototcol and managed to make it work but I didn't get a chance to clean up my script: https://gist.github.com/patrick-samy/df33e296885364f602f0c27f1eb139a8

The magic sequence to trigger the live data is: ser.write(b'\x7d\x81\xa1\x80\x80\x80\x80\x80\x80')

Following that, all data packets should be 9 byte in size, 6 and 7 being the actual values.

gabeerion commented 6 years ago

Wow, this is so great! Thanks for sharing, I'm looking forward to trying it out. I'd love to know how you figured out the magic sequence -- but I'm guessing it just involves being a bit more knowledgeable about snooping on the Windows API calls? :)

Follow-up: This works perfectly! Can't thank you enough for the help.

nchaverou commented 6 years ago

@patrick-samy : works perfectly on my side as well, thanks indeed for figuring this out Same question than @gabeerion, how have you figured out this ? It's totally non standard and I'm really interested about the process :)

nchaverou commented 6 years ago

Was about to write a little program to analyze the data but bytes 6 and 7 always return me 96 or 0 Anyone else experienced this ? Best

nchaverou commented 6 years ago

Actually packets are still 5 bytes (at least in my device on 4.6) and follow the rules defined here: http://www.atbrask.dk/?p=244

patrick-samy commented 6 years ago

@gabeerion @nchaverou I've used the same technique as the one described in this blog to spy on the official software. The only difference was that I did it in a virtual machine with a passthrough driver because I was on a Macbook Pro.

http://www.atbrask.dk/?p=244

Then I tested multiple sequences and it turns out that the software provided sends a bunch of them but only the last one triggers the live streaming of measurements.

Hope that helps!

xero3g commented 5 years ago

Can anybody send working live data code for 4.6 my way?

Pagey commented 5 years ago

@gabeerion I did reverse the 4.6 prototcol and managed to make it work but I didn't get a chance to clean up my script: https://gist.github.com/patrick-samy/df33e296885364f602f0c27f1eb139a8

The magic sequence to trigger the live data is: ser.write(b'\x7d\x81\xa1\x80\x80\x80\x80\x80\x80')

Following that, all data packets should be 9 byte in size, 6 and 7 being the actual values.

you can see this sequence and protocol in https://github.com/InfantLab/Contec-Pulse-Oximeter-in-Matlab