The article seems to be from the Qualcomm perspective. This device draws from many technologies beside Qualcomm communications infrastructure, but that gives it a big bandwidth boot. I worked at Cardionet when they started up, for about a year. Great concept, well realized. The device contained a small GPS receiver so as to be able to report your position (if outdoors), or the location of the door you entered (GPS doesn't work well inside buildings).
However the belt-worn device does more than simply send the patient's heartbeat waveform to a monitoring center. It actually performs a realtime cardiac waveform analysis, looking for specific anomalies and arrhythmias, comparing levels against physician-defined thresholds. Only when a threshold is exceeded is an action taken. See bullet 4 from in the diagram.
The problem with noise (more correctly called artifact) is that it can't be distinguished from the signal by filtering - it's in the same band as the signal. These artifacts come from chest muscle movement - breathing, bending, etc. Remember - the signal you're looking for is electrical impulses in muscle tissue. There are always concerns that lowpass filtering of DC offsets will affect the fidelity of the waveform - some of the data of interest is the slow-moving S-T segment (the area just after the 'blip'), used to monitor for some heart conditions. If the low-pass filter is set too high it distorts this part of the waveform. Filtering doesn't impact arrhythmia monitoring, tho, so the filters for devices that just monitor for heart rate anomalies can use less exotic filtering, which means that the dynamic range of the A/D can be less - 9-12 bit samples. Also, real in-hospital EKG monitors usually sample five to twelve channels, at up to 500Hz sampling rates.
Storage is the other issue for ambulatory cardiac monitors. These typically monitor three channels. At 12 bits/channel, 240 samples/second, three channels requires 1080 bytes of storage per second. A patient being monitored for 48 hours will require 186 MBytes of storage. We used flash memory in a device I helped develop. Some of the older devices stored their data on magnetic tape.
His name was Parviz Soltan and he was Persian with an interesting accent, working at Naval Ocean Systems Center in San Diego. The woman was from a university in the Bay Area (Stanford, I think). I left the project at the time she was seeking funding to explore her ideas (I was the programmer that did the fun little demo of the sub driving around under the aircraft carrier).
Interesting device. I developed the software used on the NOSC/SPAWAR laser-based volumetric display back in '96. It used a rotating two-bladed helix, in which each blade traveled from the top of the volume to the bottom of the volume as it rotated through 180 degrees. With two blades on a 600 RPM spindle, we got 20 frames/sec update - right on the cusp of image jitter. We used a Krypton/Argon laser and a prism to get RGB, and fed each primary color to a separate pair of acousto-optical devices steered by my program, which got an interrupt each time one of the blades crossed through zero degrees. The display space was 4096 by 4096 by 4096(polar coords), by using 12-bit D/A converters controlling X and Y, and 4096 slots in the display controller's memory, one for each of 4096 angles of rotation in 180 degrees.
Our major limitation was the decay rate of the acousto-optical devices, which limited the speed at which we could randomly paint the voxels in our volume. We did, at most (if I remember correctly) about 40,000 voxels per 20th of a second. As a result, we were limited to wire frame images.
eCos's main competition was Wind River's VxWorks, and pSOS (which was bought by Wind River a couple of years ago). RTEMS (an open source RTOS) remains free. eCOS was in my opinion the best-of-breed of the free RTOSs, with ports for a few modern low-power highly integrated processors. Our SA1110 device, under VxWorks, needs about 600K for the OS and our application, and about 1.5M for data (the app used ~1.1M of that. Our app needed hard real time - we werre monitoring a cardiac patient's heart, and the sampling interval doesn't tolerate a lot of jitter. Linux just wouldn't shrink to our space constraints.
Slashdot Mirror
The article seems to be from the Qualcomm perspective. This device draws from many technologies beside Qualcomm communications infrastructure, but that gives it a big bandwidth boot. I worked at Cardionet when they started up, for about a year. Great concept, well realized. The device contained a small GPS receiver so as to be able to report your position (if outdoors), or the location of the door you entered (GPS doesn't work well inside buildings).
However the belt-worn device does more than simply send the patient's heartbeat waveform to a monitoring center. It actually performs a realtime cardiac waveform analysis, looking for specific anomalies and arrhythmias, comparing levels against physician-defined thresholds. Only when a threshold is exceeded is an action taken. See bullet 4 from in the diagram.
The problem with noise (more correctly called artifact) is that it can't be distinguished from the signal by filtering - it's in the same band as the signal. These artifacts come from chest muscle movement - breathing, bending, etc. Remember - the signal you're looking for is electrical impulses in muscle tissue. There are always concerns that lowpass filtering of DC offsets will affect the fidelity of the waveform - some of the data of interest is the slow-moving S-T segment (the area just after the 'blip'), used to monitor for some heart conditions. If the low-pass filter is set too high it distorts this part of the waveform. Filtering doesn't impact arrhythmia monitoring, tho, so the filters for devices that just monitor for heart rate anomalies can use less exotic filtering, which means that the dynamic range of the A/D can be less - 9-12 bit samples. Also, real in-hospital EKG monitors usually sample five to twelve channels, at up to 500Hz sampling rates.
Storage is the other issue for ambulatory cardiac monitors. These typically monitor three channels. At 12 bits/channel, 240 samples/second, three channels requires 1080 bytes of storage per second. A patient being monitored for 48 hours will require 186 MBytes of storage. We used flash memory in a device I helped develop. Some of the older devices stored their data on magnetic tape.
His name was Parviz Soltan and he was Persian with an interesting accent, working at Naval Ocean Systems Center in San Diego. The woman was from a university in the Bay Area (Stanford, I think). I left the project at the time she was seeking funding to explore her ideas (I was the programmer that did the fun little demo of the sub driving around under the aircraft carrier).
Interesting device. I developed the software used on the NOSC/SPAWAR laser-based volumetric display back in '96. It used a rotating two-bladed helix, in which each blade traveled from the top of the volume to the bottom of the volume as it rotated through 180 degrees. With two blades on a 600 RPM spindle, we got 20 frames/sec update - right on the cusp of image jitter. We used a Krypton/Argon laser and a prism to get RGB, and fed each primary color to a separate pair of acousto-optical devices steered by my program, which got an interrupt each time one of the blades crossed through zero degrees. The display space was 4096 by 4096 by 4096(polar coords), by using 12-bit D/A converters controlling X and Y, and 4096 slots in the display controller's memory, one for each of 4096 angles of rotation in 180 degrees.
Our major limitation was the decay rate of the acousto-optical devices, which limited the speed at which we could randomly paint the voxels in our volume. We did, at most (if I remember correctly) about 40,000 voxels per 20th of a second. As a result, we were limited to wire frame images.
eCos's main competition was Wind River's VxWorks, and pSOS (which was bought by Wind River a couple of years ago). RTEMS (an open source RTOS) remains free. eCOS was in my opinion the best-of-breed of the free RTOSs, with ports for a few modern low-power highly integrated processors. Our SA1110 device, under VxWorks, needs about 600K for the OS and our application, and about 1.5M for data (the app used ~1.1M of that. Our app needed hard real time - we werre monitoring a cardiac patient's heart, and the sampling interval doesn't tolerate a lot of jitter. Linux just wouldn't shrink to our space constraints.