Someone On The Linux Foundation Who Shares Our Goals http://www.linux.com/news/featured-blogs/200-libby-clark/668154-the-people-who-support-linux-brazilian-developer-hacks-health-care-with-beagleboard-and-android
Ira Laefsky
The People Who Support Linux: Brazilian Developer Hacks Health Care with BeagleBoard and Android
Tuesday, 20 November 2012 11:00 Libby Clark |
Exclusive
Submit to Linkedin Submit to Stumbleupon
A few years ago, Brazilian developer Daniel Neis Araujo couldn’t imagine building open source health care equipment that could compete with traditional and respected proprietary solutions. But recent advances in Linux and the open hardware movement have allowed a faster development pace and a lower cost of entry for startups in the telemedicine field, in particular, he said.
Developer Daniel Neis Araujo lives in Florianópolis, the state capital Santa Catarina in the south of Brazil.
So six months ago he co-founded Atto Systems Engineering in Florianópolis, Brazil, with the aim of making intercommunication between medical devices better and cheaper. They’re using Android on BeagleBoard to help solve some critical issues, including system consistency after crashes over time, touchscreen interfacing, supported hardware and overall system performance.
“We think that if we can push a little more of the “linux philosophy" into this field, we'll make it better,” Neis Araujo said via email.
The startup has faced some criticism from the health care establishment for its open source technical approach, he said. But they’re trying to solve problems that would otherwise have no commercial viability.
“When a few kids, in a short time … creat(e) solutions as good, as stable and cheaper than the few proprietary ones, well, they are magicians (not the case), or the technical tools they use must be really powerful,” Neis Araujo said.
Open Source Professional
This is not his first open source project. Neis Araujo has worked since 2005 as a developer on Moodle, a Learning Management System at Federal University of Santa Catarina that provides virtual classrooms for teachers and students to interact via forums, quizzes and other activities.
He later went to work for the university, helping to maintain its main Moodle deployment and assist in e-learning undergraduate and post-graduate courses. He’s worked with Linux since taking an undergraduate computer science class in 2004.
“Today, the whole infrastructure we use for the Moodle deploys at UFSC are based on Linux, Apache and MySQL (and recently we're trying Nginx),” he said. “I help tune and keep all these services running for 500K+ visits / week.”
He recently joined The Linux Foundation as an individual member to give back to the community and get more involved with kernel development. Welcome Daniel!
From: Ira Laefsky [mailto:lae...@comcast.net]
Sent: Tuesday, November 20, 2012 6:00 PM
To: 'Charalampos Doukas'; physi...@googlegroups.com; lae...@comcast.net; 'Emery Premeaux'; 'Mike Dodaro'; 'ira.laefsky'
Subject: RE: Defining A Minimum Configuration This Seems To Be Our "Barier to Entry/To Beginning"
Hi All:
In answer to Charlalampos’ request I have compiled a list of the commercial (Digital) and Self Built (Mostly Analog Biosensors I know of and their URL’s) for those of you who may not have access to the shared Google Doc I have enclosed a copy of the document. I have also included a link to several open source software libraries for these devices.
Please keep the comments and suggestions coming.
--Ira
Initial Notes On Health/Fitness Physiology Digital Devices and Their Protocols
N.B.: On Charalampos’s suggestion I am starting a document on digital health/fitness and physiology devices such as Zeo, Neurosky, Fitbit, etc. that may be interfaced with our proposed Physiology Data Aggregator. Two important resources for this compilation are http://quantifiedself.com/tools/ and http://quantifiedself.com/guide/ . One good example of the information on communication protocols we should collect is the following PDF from Neurosky:
An Important source of Open Source Drivers for Devices such as Fitbit, et is http://www.openyou.org/ .
Commercial Health & Fitness (Digital) Appliances
Fitbit : http://fitbit.com/
Neurosky http://www.neurosky.com/
Bodymedia http://www.bodymedia.com/
Polar http://www.polarusa.com/us-en
Emotiv http://www.emotiv.com/
Zeo http://www.myzeo.com/sleep/
Whitings Scale http://www.withings.com/en/bodyscale
OMRON Blood Pressure Monitors http://www.omron.com/products/heal.html
Basis Multisensor Armband https://mybasis.com/ (Ira-I have email & Phone Contacts)
This is a source of Open Source Libraries for Emotiv, Fitbit, OMRON, Zeo, etc.
http://www.openyou.org/libs/
I also have contacts at Neurosky for Software Development
DIY (Mostly Analog) Physiological Sensors
GSR
Pulse/Heart Rate
Respiration
SPO2 (Seeedstudio’s system probe is digital but attachable to multiple devices)
Simple Eye Tracking (Head Mounted) or EOG
From: Charalampos Doukas [mailto:ch.d...@gmail.com]
Sent: Tuesday, November 20, 2012 2:20 PM
To: physi...@googlegroups.com
Cc: Emery Premeaux; Mike Dodaro; ira.laefsky; lae...@comcast.net
Subject: Re: Defining A Minimum Configuration This Seems To Be Our "Barier to Entry/To Beginning"
Hi all,
Ira good thought on that. I suggest we (someone please create a google spreadsheet and share) divide devices into two categories: commercial with open APIs (like Fitibit and Zeo) and custom ones (like a pulse sensor) - maybe we need to find a better definition - for those that data can be directly acquired (by the aggregator, g/w, etc.).
I have built a J2EE application that communicates with the Fitbit API and retrieves my fitness data, I could share the code and the logic for integrating it into the aggregator device.
Best,
Charalampos
On Nov 20, 2012, at 7:58 AM, Ira Laefsky <lae...@comcast.net> wrote:
Hi Everybody:
In thinking about what might be preventing us from making more progress, it occurs to me that we should agree on some minimal configuration for the health/physiology aggregator that includes at least one digital appliance, like Fitbit, Zeo or
Neurosky and two to three analog DIY devices like GSR, Pulse Sensor and or Respiration/SPO2 sensor. These should attach to either a single microcontroller like Arduino or via easy outboard connections to a simple Linux Processor like Beaglebone
Or Raspberry PI and transmit the data from all attached devices via a PC or Wifi Router to some Cloud or Internet of Things Service. I am not committed to any particular implementation of this minimal system, but I am “throwing it out there” as an idea of a minimal configuration to get your comments and suggestions.
Thanks --Ira Laefsky
From: "Ira Laefsky" <lae...@comcast.net>
To: "Emery Premeaux" <epre...@gmail.com>, "Mike Dodaro" <gmdo...@hotmail.com>,lae...@comcast.net, "ira.laefsky" <ira.l...@gmail.com>, "Charalampos Doukas" <ch.d...@gmail.com>
Sent: Sunday, November 4, 2012 1:22:49 AM
Subject: Back On The Internet/Eager For Feedback/Still Questions/Some STrawman
Hi Everybody:
Thank G-d totally recovered from storm back with phone, internet and tv as of today. I am eager to move with the momentum we have reignited.
One problem faced by users of health and fitness data involves the multiplicity of data formats coming from digital health appliances like Fitbit, Zeo, Neurosky, Emotiv and MyBasis.
These each have “gozintas” like USB, Bluetooth, etc. and have a proprietary (even if openly shared) digital data format. Emery please correct me -- but if we wish to accept data from these digital devices as they spit it out, in addition to the ADC streams coming from our own DIY devices (e.g. GSR) is it possible to get this digital data in a proprietary format into a CSV form without any translation??? My question in the previous note was whether we wish to provide a general interface to a variety of digital health/fitness appliances each with a unique data format or do we need to address such devices one at a time? By the way EDF and EDF+ http://www.edfplus.info/specs/edfplus.html are the European Standard for Exchange of
Physiological Data rather than a web document format they are commonly used in Sleep and Neurophysiology Labs—but if there is a simple general solution to sopping up digital data
coming from a variety of proprietary devices I am eager to hear more about it?
I agree that we want to use an embedded computer with a real operating system (probably Linux) unless Microsoft funds our effort, or we work with an extended Android Tablet.
It would be nice to have some kind of LCD Panel display for data display and control menus for the device, but the gozintas’ for USB and wired/wireless interfaces and some way of getting multiple channels of ADC input for our home-built analog devices is probably a higher priority. Incidently, is anyone aware of a tablet-like device with better I/O and SPI I2C interfaces?
I am definitely ignorant of many of the important technologies which we will need to adapt to our application and I am particularly looking toward Emery and Charalampos for guidance
Thanks to all for their concern during the hurricane and I look forward to bouncing ideas with you.
--Ira
ira.m.laefsky on SKYPE
ira.l...@gmail.com for google chat
From: Emery Premeaux [mailto:epre...@gmail.com]
Sent: Thursday, November 01, 2012 8:39 PM
To: lae...@comcast.net; Mike Dodaro; ira.laefsky; Charalampos Doukas
Subject: Re: Still Without Phone and Internet At Home Brief Note From Public Library
Glad you are all ok.
Been catching up on internet news here. Crazy storm.
Poor Jersey.
Re topic:
Im not sure a format like EDF is necessary on the device itself. These web style data formats are fine on a pc with gobs of cpu and ram power. They offer easy extensibiity with a tradeoff in complexity. Lower end devices really cant handle all that overhead.
If it were me, Id leave the device to aquiring, logging and transmitting. Deal with the raw data. On a special purpose unit I might add display where needed.
Leave the repackaging to a desktop or web service app.
So, a simple and FAST data format for the device. This leaves as much cpu and ram to acquiring signals as possible. Data can always be filtered or decimated later.
A simple csv with a good header scheme is best, and leaves it open for even arduino to acquire reasonably fast signals. (With a very tight program loop, it can pull and transmit over serial port around 200 samples of 3 adc channels per second. Once we add writing to an sd card, maybe 150. Just a guess. If we were to spend a lot of cpu time packing that into a complex format, we might do worse than 1/4 our fastest sample rate.)
This would mean a good menu system in which the user identifiescthe type of device and channels is all thats needed.
lae...@comcast.net wrote:
Hi All:
Thank G-d storm only affected utilities power (one day) phone tv and internet thru now but home and family ok.
I am eager to continue with our progress on the aggregator when we are back in touch and I agree that a use case combining charlampos and I(my) experimental academic use case and
that of a "lifelogger"/quantified self fitness enthusiast is the best starting point. One major question is whether (initially) we begin with translating digital appliances like the fitbit or neurosky
on a case by case basis (translating the digital interface protocol from a single format to a local data format) or try to do this (translate the data formats generally into a common intermediate data
format like EDF+ in a general way) do any of you or Charalampos in particular have any ideas in this regard?
My initial thought is that we define an initial set of functionality say GSR and pulse and one device (Neurosky or Fitbit?) as an initial platform for experimentation.
Could you forward your thoughts that I hope to read Sunday or Monday (utilities permitting).
Many Thanks
--Ira
lae...@comcast.net
From: "Emery Premeaux" <epre...@gmail.com>
To: "Charalampos Doukas" <ch.d...@gmail.com>, "Ira Laefsky" <lae...@comcast.net>
Cc: "Mike Dodaro" <gmdo...@hotmail.com>, "<lae...@comcast.net>" <lae...@comcast.net>, "<ira.l...@gmail.com>" <ira.l...@gmail.com>
Sent: Monday, October 29, 2012 6:56:55 PM
Subject: Re: Some Brief Items While Internet is Up/Worst of Storm Hasn't Hit Yet
Goid luck sir. Built an arc yet? ;)
Charalampos Doukas <ch.d...@gmail.com> wrote:
Ira thanks for the thoughts, I think we are on the same wave, hope all goes well and safe with the storm!
Best,
Charalampos
On 29 Οκτ 2012, at 23:21, "Ira Laefsky" <lae...@comcast.net> wrote:
Hi Everyone:
Please excuse some disorganization while the storm is uppermost in my mind—
1. This is a good source of the tools and commercial appliances that we may wish to supply a translator/translation API for (like Zeo, Fitbit, Mybasis, Neurosky, Polar):
2. Google Docs would seem to be a reasonable place to store our lists and commonly held notes that we can jointly edit. If either Charalampos, or Emery is on the net in my absence
(due to the storm) we might want to start a list of commercial and separately DIY appliances. My google address is ira.l...@gmail.com
3. I am unsure if we want the design and prototyping platform around a specific set of commercial appliances (1 or 2) and specific DIY sensors, GSR, HR, Respiration or be as general as
possible to first specify a general API that allows translation of many digital protocols there are tradeoffs in each direction you Emery and CHarlampos may be the best judge of this.
Please excuse my lack of availability till toward the end of this week people are talking about a storm of the century – I hope an exaggeration
--Ira
From: Emery Premeaux [mailto:epre...@gmail.com]
Sent: Sunday, October 28, 2012 8:10 PM
To: Charalampos Doukas
Cc: Ira Laefsky; Mike Dodaro
Subject: Re: Charalampos: Could You Guide Me With Questions On My Initial Idea of Use Cases? Thanks -- Ira
Absolutely.
Email is going to be hard moving forward. Esp documentation. These convos should be pushed to the googlegrouo, and as rusults start to materialize a wiki or somesuch.Charalampos Doukas <ch.d...@gmail.com> wrote:
I totally agree with Emery on this,
It is a good starting point to collect the use cases, but indeed I don't think we can address them all at once. Maybe start grouping them first, for example, the first two use cases defined by Ira (thank you Ira btw), looks like they can be grouped to one use case.
So for the first case, I would collect examples of existing devices and systems (Fitbit, etc.) and also make a second list with DIY devices (like the GSR sensor).
Should we make an online form all could edit, for collecting the latter information?
Best,
Charalampos
On Oct 28, 2012, at 6:35 AM, Emery Premeaux <epre...@gmail.com> wrote:
I am of the opinion that a solid base device and a framework of software come first, and actual use cases grow and are designed organically.
Right now the ide seems to be "one to rule them all" byt is trying to satisfy all those needs up front. This is a rather tall hill to climb.
Benefits of modularity is compartmented development. Lets choose ONE use case, and start there.Ira Laefsky <lae...@comcast.net> wrote:
Charlampos:
I have little experience in the specification of a hardware software system such as this, but these are the three general uses I see for our aggregator. Might you guide me in fleshing this out by asking questions about each use?
Much Thanks for Any Input
---Ira
From: Ira Laefsky [mailto:laefsky@comcast.net]
Sent: Friday, October 26, 2012 2:19 PM
To: 'Emery Premeaux'; 'Charalampos Doukas'; 'Mike Dodaro'; lae...@comcast.net
Subject: One (Rough) Sentence Introduction to Three Use Case Themes
I don’t have time this afternoon to flesh this out but I believe there are three major use cases for the Physiology/Health Aggregator. I welcome your comments before we flesh this out to more formal use cases.
1. Quantified Self Types (I strongly recommend you look around the http://quantifiedself.com and its related sites) users who have one or several digital health appliances (Fitbit, Zeo, Neurosky, mybasis.com (watchband multisensory), polar heart sensor, Seeedstudio SP02 Sensor, Whitings Scale) and perhaps one or two home built sensors such as GSR (Skin Resistance) who wish to see all their Health and Fitness Information in one common (viewable) website or database and perhaps have
The application which goes with the site/database make predictions on their future health &/or athletic performance.
2. Researchers (academic or health/medicine sciences or human-computer interaction) who wish to gather reliable data at a single point and record it while the user performs a task. In my particular case (perhaps not the best one to model) I will
Eventually want to record EEG (maybe), Eye Tracking Data, GSR, Respiration and Heart Rate Variability as user read from the screen in a particular cognitive task (e.g. a reading comprehension exercise). These researchers will often want for
This data to be analyzed by Machine Learning Algorithms or Statistical Tests on the host web site or database.
3. A Telemedicine Health Data Hub where physicians meeting their patients in an online video session can simultaneously record measurements to supplement their recommendations, these might include EKG, Blood Glucose Measurements, etc.
This is an application that should influence are thinking but where we do not aim to have a fully fleshed out FDA-type approved appliance. Take a look at this: http://www.freescale.com/webapp/sps/site/application.jsp?code=APLTHS
--Ira
From: Emery Premeaux [mailto:epre...@gmail.com]
Sent: Friday, October 26, 2012 1:09 AM
To: Ira Laefsky; 'Charalampos Doukas'; 'Mike Dodaro'
Subject: Re: Need Pointer on Nanoscope
no. Sorry.
Im referring to the DSO Nano and DSO Quad oscopes here:
http://www.seeedstudio.com/depot/hacking-measurement-c-174.html
Im strongly considering the quad as is for electronics work, and the nano for pocket sensor hacking.
A couple of gus in Safecast are hacking a nano into a scintilation spectrum analyser to identify radioactive isotopes.
Ira Laefsky <lae...@comcast.net> wrote:
Emery:
Being unfarmiliar with the Nanoscope project I googled and found some description of a “digital microscope” is this the project you are referring to? And if so how does it apply to electronic biosensing--Thanks
From: Emery Premeaux [mailto:epre...@gmail.com]
Sent: Thursday, October 25, 2012 11:22 PM
To: Ira Laefsky; 'Charalampos Doukas'; 'Mike Dodaro'
Subject: Re: NANO PC/Freedom Box/ Apologies To Emery On Not Noticing His Raspberry PI Coments
One serious platform to consider is modding the open source nanoscope project.
Ira Laefsky <lae...@comcast.net> wrote:
Hi All:
First of all I would like to apologize to Emery on not noticing his comments on Raspberry Pi, I believe (fact check me) that Raspberry and Broadcom have released all I P on the PI including GPU IP into the Open Source Community in the last few days
As far as the supply problems go, perhaps with the entry of Element 14 Farnell into the Raspberry arena the supply problems may improve but they are still real.
It might allow us to concentrate better on the sensors and the code if we looked at a Micro/Nano PC (running eitherWindows or Linux) or one of the Freedom Box targets or a Plug Box Computer running Linux, the I/O could be easier. We could
Then take the running Linux or Windows code and rehost to a Beagleboard XM or Atom PC Board after the simpler development on a finished device rather than a development board, but you Emery & Charalampos are in a better position to comment
On this idea.
Thanks to everybody and sorry if I issed anything in the recent activity I hope we can keep it going and reinvolve others.
From: Ira Laefsky [mailto:lae...@comcast.net]
Sent: Thursday, October 25, 2012 1:59 PM
To: 'Charalampos Doukas'; 'Mike Dodaro'; 'Emery Premeaux'; lae...@comcast.net
Subject: Thanks Everybody for Your Thoughts--Some More Anecdotal Thoughts On Physiology Health Aggregator
Thanks Charalampos, Emery & Mike:
Thank you all for your thoughts and contributions, I haven’t yet thought this out as well as the rest of you (in reference to incentivization, and architecture) but I do have a few random thoughts to contribute. I do hope we can reestablish momentum
on this project and make great things happen.
Some thoughts (not in any particular order):
1. On incentivization and data sharing: In the U.S. the data must come from the individuals rather than a health institution (I believe) for the data to be legally shared—HIPAA privacy rules prohibit providers from making data available to third parties I don’t know if there is an exception if the patients give specific approval, or if the data is anonamized (sic). Getting individuals to contribute their data from health sources might be incentivized either by providing information back to the individual
(via a web site, printed report, or wiki), or by financial incentives coming from a service provider--I understand that at some point in their existence TIVO gave a discount to their subscribers if they would allow data to be aggregated and reported back to advertisers.
2. Quantified Self & groups of self trackers are an important audience for this type of information and the aggregator. There are large numbers of individuals who wish to keep track of their own health and fitness data and are fans of this practice. I highly recommend that any of you who haven’t already done so look at http://quantifiedself.com andhttp://quantifiedself.com/guide/
3. On Hardware: One board that is worth at least looking at in addition to the Beaglebone/Beagleboard is the Raspberry Pi, It has several video and I/O options on board that are not available through the Beagle family and the Eve Alpha that Charalampos mentioned as an IOT/communications device is built around this architecture. One other possibility to simplify development might be to use a mini pc or small linux box like the freedom box target architectures see http://wiki.debian.org/FreedomBox/TargetedHardware andhttp://freedomboxfoundation.org/
Please keep the thoughts and notes and use cases coming they are invaluable to me and to the project.
--Ira
From: Charalampos Doukas [mailto:ch.d...@gmail.com]
Sent: Thursday, October 25, 2012 12:53 PM
To: Mike Dodaro
Cc: Emery Premeaux; Ira Laefsky
Subject: Re: Some Thoughts To Get Physiology Aggregator Back On Track/ I Will Be Most Greatful for Your Reactions
Very good examples! So, one thing we need, is input from users, what are their problems? My first recommendation about research, came as a need to me. I had never thought that there could be cases where scientist drive research to satisfy funders (in greece we don't have companies funding universities…), but still it is a good example why people might want to 'donate' their data (though we might not be able to use that argument officially :-)
Your DHEA supplement use case, perfect fit for a social tool that combines activity data with supplements and nutrition.
I suggest we go back one more step, start writing down the use cases!
Ira would you mind starting a shared document for collecting such uses cases?
On Oct 25, 2012, at 7:41 PM, Mike Dodaro <gmdo...@hotmail.com> wrote:
My question about why users would share physiological data was not necessarily skeptical; it was a question about motivation. I am a physical culturist and have been since my teens. I lift weights and run. I take food supplements. I read research about such things, but I am very skeptical about the research. A great deal of medical research is a corruption of science by the pharmaceuticals industry. To back up a statement like that I note that we have many people at Microsoft who were educated at prominent institutions. In a discussion of medical research, a guy who used to play basketball with researchers at Stanford recalled how cynically the researchers joked about giving the funders what they wanted to keep the funds coming. One reason people might want to provide data is to circumvent the vested interests in research funding.
Health care costs in the American economy are higher than the defense budget. Fitness is a very profitable business, from weight loss to peak performance. What compelling reasons can we find to motivate participation. Which technologies can we make available to participants without the millions of dollars availble to researchers at Stanford University?
Here is an example that could interest me: I take DHEA supplement. It would be intesting to me to know the levels of DHEA of people my age particularly in relation to their physical fitness.
Subject: Re: Some Thoughts To Get Physiology Aggregator Back On Track/ I Will Be Most Greatful for Your Reactions
From: ch.d...@gmail.com
Date: Thu, 25 Oct 2012 19:10:21 +0300
CC: epre...@gmail.com; lae...@comcast.net
To: gmdo...@hotmail.com
Mike,
I completely understand your scepticism about the value of sharing physiological data. It is similar to when thinking about an IoT-related product, why would people use it and how companies can make money?
Here are some thoughts (feel free to think of them as a small business plan) about sharing data (not just collecting and visualising them, I think that part is already attractive to users):
1) Some people would share data (anonymously) for research. Think of collaborating with universities (I wonder now if Microsoft Health Vault is already doing this or has ever thought of it). My biggest problem during my PhD was getting real data from real people and analysing them to find patterns, detect anomalies, predict behaviours. I bet that there will be institutes willing to pay Microsoft (or whoever does this) a fee for having access to such data.
2) Give people some reward for sharing data: Fitbit for instance (recently I got a Fitibit Ultra activity tracker) provides a virtual reward system for stimulating users to be more active (walk a lot, climb up chairs, etc.). How about having a platform where people get discount rewards (like coupons) for achieving specific goals? That system shall not be tight to a specific platform (like fitbit) but shall be open to any vendor/product (Withings, Zeo, etc.)
3) Integrate the social network craziness to the physiological data: not just posting how many km I have run today, but allow users to compete their performances through social platforms.
4) Data mining: All aforementioned systems truly lack the functionality of analysing user's data and making predictions or associations with their health status, nutrition, behaviour, etc.
I have built a 'proof-of-concept' system that predicts the next day's activity based on fitbit data of previous days. The system can take parameters like my daily schedule or weather forecast and recommend what kind of activities I shall do to remain within my weekly calories burning target. I am sure people would use that.
How companies (like Microsoft) could make revenue out of such a platform, that's a different story, but I am sure all of us can think ways to monetize physiological and health-related data!
So, my concerns are not about how to convince people, rather how to achieve proper data collection through a number of different services and devices. That is the real challenge gentlemen. The open source data aggregator, as a hardware system, could facilitate data collection for devices that are not commercially available yet (like Withings or Fitbit): think the GSR sensor as a stress level indicator. But then we also need a back-end infrastructure with open APIs and integration of existing APIs (for data aggregation from different sources).
Btw, I have recently posted about IoT and data mining, hopefully it can give you guys some more understanding of data mining techniques and what they can be used for: http://blog.buildinginternetofthings.com/2012/10/13/data-mining-and-the-iot/
Charalampos
On Oct 25, 2012, at 6:38 PM, Mike Dodaro <gmdo...@hotmail.com> wrote:
A couple of pertinent details from here: Windows Embedded Compact works with Beaglebone. WEC is paying my wages right now.
I've worked at Microsoft for more than 15 years. It was nearby when I learned to program and continues to provide useful tools, many of them for free, but it is evident that Microsoft is losing ground to Google's model that enables anybody to put a blog or video online.
I think Emery is correct that removing obstacles to entry for growing numbers of participants is the new way, contra the Microsoft way of eliminating or assimilating competitors.
What is the health and fitness equivalent of Blogger or You Tube? Why would anybody want to share their physiological data or offer it up to be aggregated?
From: ch.d...@gmail.com
Subject: Re: Some Thoughts To Get Physiology Aggregator Back On Track/ I Will Be Most Greatful for Your Reactions
Date: Thu, 25 Oct 2012 10:59:19 +0300
To: epre...@gmail.com; lae...@comcast.net; gmdo...@hotmail.com
Hi All,
Ira thanks fro bringing back the discussion, Emery thanks for the ideas about Beaglebone. I agree with Emery's approach, but first I think we need to define the system requirements through a basic use case.
I suggest we start with:
1) A heart beat sensor
2) A GSR sensor
Also, keep in mind additional sensors and wireless technologies to be integrated, as well as API interfaces to systems like fitbit or the Zeo Sleep monitoring system (as Ira has also suggested in the past).
To me the option is to go with wireless sensors, meaning that even if we use sensors with a wired interface (like this one from Seeedstudio: http://www.seeedstudio.com/depot/grove-earclip-heart-rate-sensor-p-1116.html?cPath=197) we add some wireless interface using a microcontroller like the Arduino and some wireless interface (like Bluetooth or XRF).
Clearly the aggregator will need to have various wireless interfaces to support communication with the sensors. I recently came across this module (soon to go live): http://www.kickstarter.com/projects/1329906826/1438179140?token=3ba0a23b
The aggregator (from a hardware's perspective) should be something similar to Eve. Supporting several wireless interfaces, at least one Internet interface (Ethernet or WiFi) and a computer module (we all probably agree that something more powerful than an Arduino or a Gadgeteer is needed to collect signals and send them to some Cloud infrastructure).
Another idea would be to include in the system an Android-enabled HDMI usb dongle that could be connected to HDMI TVs and provide an interface for visualising the aggregated data.
In addition to the hardware, we also need to think of the software. How signal data will be interpreted form the aggregator? We clearly need to define some kind of protocol so the aggregator knows when heart beat data is received and when GSR is.
So, many ideas, many requirements. One fundamental thing to begin with: I suggest we split the group to two teams: one team dealing with the hardware challenges (suggesting sensors, interfaces, etc.) and one team with the software (suggesting protocol, communication, etc.).
Some initial thoughts!
Best,
Charalampos
On Oct 25, 2012, at 9:54 AM, Emery Premeaux <epre...@gmail.com> wrote:
Why Beaglebone and not raspi or fidgets or whatever?
1: as a community project by which lower skill levels is encouraged to try, fulfillment is key. I can rant for hours about everything wrong with the pi project. Suffice to say that as long as they continue to offer artificially low prices based on handshake only agreements with their suppliers, they'll never fulfill orders on time.
2: its also wise to avoid closed sorces in open source dev. Anything devd on the beaglebone should port to anything running linux, with minor adjustments and a fresh compile. Avoidmicrosoft.net like projects and the like.
A big complaint about armcore dev is the fact that a lot of the ide/compiler stuff out there is for pay. There is an open source toolchain, but its not all that easy to work with. Avoid being just another product demo.
Ira Laefsky <lae...@comcast.net> wrote:
Charalampos, Emery & Mike:
It was great to be back in touch with you recently and I hope (over the next couple of weeks) to write to you personally at greater length. In the interim since you have agreed to advise me within the real limits of your busy schedules
on our physiology/health data aggregator device(application) I thought I would put out some initial thoughts for your reaction. I would be most grateful if you could respond with any thoughts of your own especially on scope and feasibility.
As you may know from previous discussions my personal interest in a physiological aggregator is to collect psychophysical responses as an experimental subject reads from the screen. Obviously, the much larger need for such a device
Is for individuals (“life loggers” “Quantified Self” participants) to collect their own health and fitness data online and compile this data into a kind of Health Vault on the Web of Things which they could analyze and share with their medical
Providers.
I would want an intelligent (probably with a real operating system Linux, Windows Embedded, or Android) “box” which is network connected and which could collect data from several (possibly self made) analog sensors,
e.g. GSR (Skin Resistance), Heart Rate & Heart Rate Variation, and Respiration, and which could incorporate at least one commercial digital sensor (one in the short term more in the future) such as the Neurosky EEG Headset.
This data could then be buffered internally on some local storage and transmitted (on demand, or continuously) to an Internet of Things Site for further analysis (possibly by Machine Learning Algorithms).
I would in particular like your thoughts on what might be a relatively simple prototype which we could construct and demonstrate with limited outside funding?
I would appreciate any thoughts you could forward me in however rough and undigested a form (Let me know what you think about this scheme J)
--Ira
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
You received this message because you are subscribed to the Google Groups "Physiosense" group.
To unsubscribe from this group, send email to physiosense...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.