Products > Test Equipment
What modulation scheme is used by the KardiaMobile ECG sensor?
(1/2) > >>
Ben321:
Unlike most other remote sensors or accessories that work with smartphones, this ones doesn't use bluetooth. It actually communicates via sound. The KardiaMobile uses an analog modulation of some kind to send a signal at nearly ultrasonic frequency (appears to be 19kHz on a spectrogram) that is then picked up by the smartphone's microphone, which the app then demodulates. I used another smartphone app to record the sound to an uncompressed WAV file with the intent to copy that file to my PC for further analysis with PC-based signal processing software to see if I could demodulate it and get the raw ECG waveform. I had assumed it would be using either plain FM or AM modulation, but it appears to be using both forms of modulation together. To further compilcate matters, the carrier tone appears to be modulated not only by the ECG waveform, but also by a 60Hz pulse. And no, it's not a line-powered device. It's battery powered. It's just that an electronically generated 60Hz pulse is also modulating the signal. And to make it even more complicated, the 19kHz tone appears to be being independantly AM and FM modulated. That is, the modulating signal for AM isn't the same signal for FM. A high amplitude of the carrier doesn't always correspond to either a high frequency or low frequency within the FM modulation range.

I checked the official website of the company that makes KardiaMobile, hoping their modulation scheme was publicly documented, but it's not. All I found is this https://alivecor.zendesk.com/hc/en-us/articles/231583848 which says this about the signal:

--- Quote ---The Single Lead KardiaMobile EKG device communicates with your mobile device through a proprietary wireless communication protocol using ultrasonic audio. The protocol does not require any pairing or bluetooth service to communicate its EKG signal.
--- End quote ---
So unfortunately it is a proprietary signal. And this is why I'm posting here about this. I hope someone here can help me to reverse engineer the modulation scheme being used. To that end, I have posted my uncompressed WAV file recording of the signal from a sound recorder app on my smartphone. Only post processing that has been done is an FFT bandpass filter to isolate the signal, and then maximizing the amplitude of the signal so it fills the range of the 16bit WAV file format. These processing steps were done with Goldwave audio editor on my PC, which while it's intended for processing music, also has some very useful capabilities for analyzing signals as well. However, despite my best efforts I haven't successfully reverse engineered the modulation scheme being used here, so I hope someone on these forums will be able to help.
Ben321:

--- Quote from: evb149 on March 06, 2022, 07:32:00 am ---If you really want to analyze the input vs output to look for functional relationships manually then maybe you should put some effort into
making a test setup which generates repeatable inputs?
--- End quote ---
Sounds like a good idea.


--- Quote from: evb149 on March 06, 2022, 07:32:00 am ---e.g. take a function generator or AWG or sound card output or something like that and feed the inputs of the device appropriately by simulated / synthesized input wave forms to the various channels.
--- End quote ---
That won't work. It's my mom's KardiaMobile, not my own personal one. She let me use it to check my own pulse, but I wouldn't dare to attach a funcgen to the KardiaMobile's input electrode pads. If the funcgen sent too strong of a signal it could damage the input stage of the KardiaMoblile. I don't know the voltage range expected by the input stage of the KardiaMobile.



--- Quote from: evb149 on March 06, 2022, 07:32:00 am ---Why are you even doing this, anyway?
--- End quote ---
As an exercise in reverse engineering, but that wasn't my initial intent. My first plan was to make a PC application that would simply receive and demodulate the signal, bypassing the Android app entirely. The mobile app requires an account (though the simplest account is free) for ANY use of the app with the external sensor. You can't take readings without an account. That seems suspious. I don't trust companies that require accounts for ALL tasks that don't seem like they should require an account for the most basic tasks (I would expect an account for cloud storage, but just basic use of the device and local storage shouldn't require an account). Any company requiring an account for the most basic usage of their hardware I don't see as trustworthy, and CERTAINLY not trustworthy enough to give their app microphone access. I mean that seems right there like they want to associate audio recordings with your account so they can track any audio in your vacinity, and then feed that audio data to AI to determine what you are saying in conversations, and then use that to generate info on personal interest, and then send that info to ad companies for targeted advertising. And then they make money from selling your info to ad companies.

So my initial goal was to as soon as possible help my mom to ditch the app on her phone, by writing alternative software for the PC (I don't have good skills writing mobile apps, but have enough PC programming skills to write PC soundcard software). While my PC software wouldn't be able to go with you wherever you are like your phone can (as well as other features like generating a PDF report based on the ECG waveform, which the official app can do), it certainly would be enough to record and demodulate the signal on the PC, and then display the ECG waveform on the screen.

It became a reverse engineering effort after I realized that the modulation scheme they are using (while it is analog, and not digital) is NOT a simple AM or FM modulation scheme, and I would need to make the effort to reverse engineer the modulation scheme they are using. I assumed this might already have been done so I searched Google for any webpages where hackers may have written up documents describing the modulation scheme in use on this device. But my googling was useless. It seems nobody had reverse engineered this yet. That's when I decided to post here, hoping that someone else had already done that reverse engineering on an EE forum like this one, and maybe if I asked about it someone here would provide me with the needed info, and if not done yet somebody might be willing to join me in my own effort to reverse engineer it.


--- Quote from: evb149 on March 06, 2022, 07:32:00 am ---An ECG waveform capture device for non-medical curiosity purposes is easy enough to capture by something someone knowledgeable in EE / analog / signal processing circuitry could make. Basically it is just some analog to digital converters with appropriately high impedance differential inputs and appropriate filtering and protection etc.  They literally make IC chips specifically for
this purpose that do mostly everything except for the filtering and protection / connector stuff and you can buy kits to do it as well.
Then you don't have to worry about the protocol since it will be documented and obvious as only ADC samples for N channels.
--- End quote ---
I don't really have a lot of room in my bedroom/lab. It's really small and I really have no room for soldering projects right now. Most of my work is on my computer, writing various software, including sometimes software for computer-connected accessories. I'm definitely on the software side of things, not the hardware side, at the moment. If I need a specific type of input into my computer, I don't build the hardware, I buy it (or in this case borrow it from my mom).
dnordquest:
Perhaps you might find some clue in the following AliveCor patent:

https://patents.google.com/patent/US8301232B2/en
Ben321:

--- Quote from: evb149 on March 07, 2022, 12:40:44 am ---I agree with you 100% about "cloud connected" devices, "apps", security risks of running untrusted software / hardware that has access to sensitive data like one's health / medical information, identity, access to voice / audio, etc.   One could say similarly about the common "voice assistants" and "smart watches" and
even smartphones / tablets / laptops / desktops themselves since usually there's a lot of undocumented / untrustworthy software in there somewhere.
Personally I wouldn't happily buy any hardware and let it connect to "the cloud" unnecessarily if possible, and generally would also suspect any network connected software, too.

--- End quote ---
That's what I'm thinking too.


--- Quote from: evb149 on March 07, 2022, 12:40:44 am ---Ok well I don't have very handy spectral analysis software for audio signals and going into the details of the signals would take too much time to look into
but with respect to modulations I can suggest the following ideas which may or may not be relevant:

--- End quote ---
I'm already very familiar with various types of modulation I'm quite familiar with both analog modulations and their digital counterparts, as well as some special ones unique ones like PWM and PPM that are based on pulses. DSP is something I do as a hobby. I have a couple different SDRs and sometimes try to reverse engineer the type of signal I see in the SDR's software's spectrogram that doesn't look familiar.


--- Quote from: evb149 on March 07, 2022, 12:40:44 am ---2: It isn't impossible they could add a signal out of band of the ECG waveform for some kind of synchronization / timing or data communications or other purpose so I guess I'd put the 40-80 Hz range or whatever through a filter and compare it to the local mains frequency noise you pick up by some other means and see if the frequency and phase correlates to your environmental noise.  If you DO NOT activate the ECG device and do a sound card recording from a microphone (especially an external one if you have one) it may well be you'll pick up enough 60 Hz from your environment to see that in a spectrum though maybe not if your sound hardware suppresses / filters it very strongly.

...


You might want to take a real ECG signal waveform you download ( there are public databases of recorded ECG signals for research / education etc. purposes) and modulate it AM, FM, whatever with varying modulation index and see what the signal looks like compared to the one you are getting.
Also even do that with pure sine waves and see what that looks like to see what similarities / differences you see with the instrument data.
--- End quote ---
I do know what an ECG waveform should look like. I suspect that a sync pulse may very well be in use in this signal. The mic I used was my cellphone's mic. There was no baseband 60Hz signal, so that isn't a possible source of the 60Hz pulses in the demodulated audio. Also I used an FFT bandpass filter to filter out verything outside of a 2kHz (slightly larger than the signal bandwidth) band centered on the 19kHz I was trying to analyze, prior to attempting demodulate it. As for how I recorded it, I placed my cellphone about the same distance from the KardiaMobile as my mom's phone was from the same device. I then used it to take my own ECG. My mom's phone was running the official app. My phone was running a sound recorder app.

The other possibility is that a 60Hz signal is being picked up by my body (acting like an antenna), and even though the leads themselves aren't long on the KardiaMobile (they are literally just pads on the device that you put your fingers on), my body still may pick up the signal and transfer it to the device. This would result in a 60Hz signal as well as the heart electrical signal being transferred into the metal pads and thus modulating the 19KHz tone.

The official KardiaMobile app on my mom's phone displayed a smooth ECG graph, with no background noise and no 60Hz pulse. The sound recorder app on my phone recorded the raw signal as an uncompressed WAV file that I then later copied over USB cable to my PC, where I have been unsuccessfully been trying to demodulate it, and for that matter been unsuccessful in determining exactly what type of modulation the signal uses.


--- Quote from: evb149 on March 07, 2022, 12:40:44 am ---Also I didn't ask and I don't think you said -- typical medical ECGs involve several channels e.g. 12.  Just for exercise equipment or sports heart rate monitors typically there is at least one single pair of leads e.g. left hand grip vs. right hand grip electrodes, or a central pad vs a side pad or whatever on a wearable bluetooth heart rate monitor. But anyway if your instrument has more than a couple of body contact electrodes it may be sending more than one channel of signal back
and maybe it does that simultaneously on different subcarriers / channels, or maybe some time alternating scheme etc.
--- End quote ---
The KardiaMobile device has 2 metal pads. You put 2 fingers on each pad. Left index and middle fingers on the left pad, and right index and middle fingers on the right pad.

Ben321:

--- Quote from: dnordquest on March 07, 2022, 01:31:00 am ---Perhaps you might find some clue in the following AliveCor patent:

https://patents.google.com/patent/US8301232B2/en

--- End quote ---

All it shows is FM demodulation in the patent.

I think I figured out why though that there is both AM and FM modulation in my signal. I looked more closely at the spectrum and noticed the higher frequencies have higher amplitudes, possibly due to the spectral response on my phone's microphone not being flat in this part of the spectrum. Then how did it work on my mom's phone with the actual app (as the app doesn't matter, if the spectral response of the mic isn't flat)? I'm guessing that not all microphones in phones are the same quality. Nor are the analog filters before the ADC. Some might not only introduce frequency dependent amplitude variations, but also frequency dependent phase variations (not visible on a normal magnitude FFT, but which could wreck your ability to demodulate FM signals). The analog LPF is needed though to block frequencies above the nyquist limit (half the sample rate) of the ADC, but they aren't all made spectrally flat, as they were never intended for scientific use when the phones were made. My phone isn't the same model as my mom's phone, so it's possible that the discrepancy in the quality of recorded signal is simply a matter of which models of phone use better quality circuits. That would also explain why the company needs to keep this list of compatible phones https://alivecor.zendesk.com/hc/en-us/articles/1500000449521-Compatibility

Some phones simply have analog audio input circuits that aren't capable of processing the received signal with enough quality to provide a processed signal that can be demodulated correctly.
Navigation
Message Index
Next page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod