Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 08, 2009 at 01:40:57PM +0100, Peter Robinson wrote: There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. That would need to be accepted upstream by the alsa project, and then distros will automatically get the changes when they are part of a release. Or (less effective but sometimes possible if in a hurry): Convince distributions to accept patches, even if upstream rejects it (or temporarily while upstream procedures might be slow). For Debian, the package this would probably land in would be alsa-firmware-loaders (if I understand it correctly), and the people to contact about it are reachabel on this email address: pkg-alsa-de...@lists.alioth.debian.org Sometimes it might even ease upstream adoption if first working with distributions on shaping/polishing patches. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknfJwUACgkQn7DbMsAkQLiJKACglphhhquwpqVytDJe1nPYRd5a 5OYAnRmVeYSjoluVH4OqbWv4cUxukrae =Ve+F -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. That would need to be accepted upstream by the alsa project, and then distros will automatically get the changes when they are part of a release. Or (less effective but sometimes possible if in a hurry): Convince distributions to accept patches, even if upstream rejects it (or temporarily while upstream procedures might be slow). Fedora at least has a fairly strict policy of using upstream only and will generally reject patches. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
On Wed, Apr 08, 2009 at 03:44:05AM -0400, Seth Woodworth wrote: I'd like to encourage everyone to build on the great work of Arjun Sarwal and help us extend the sensor interface with our peripheral -- the heart rate monitor. Looks great! As I intended to do a similar device in the future (it's going to measure SpO2 (oxygen saturation) as well as that's what I'm interested in), I'd like to see the schematics. Are they available somewhere? Do you just amplify the current through a photo transistor or is there something more fancy going on, e.g. AGC? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). -walter On Wed, Apr 8, 2009 at 3:44 AM, Seth Woodworth s...@laptop.org wrote: -- Forwarded message -- From: Tom Boonsiri tom.boons...@gmail.com Date: Wed, Apr 8, 2009 at 2:31 AM Subject: Heart Rate Monitor Peripheral To: seth.woodwo...@gmail.com Fellow developers, Is your Measure activity feeling neglected? If so, shame on you. =) I'd like to encourage everyone to build on the great work of Arjun Sarwal and help us extend the sensor interface with our peripheral -- the heart rate monitor. Pictures of the device: http://farm4.static.flickr.com/3559/3419907541_f62b168dce_m.jpg http://farm4.static.flickr.com/3558/3420715230_00e29b7787_m.jpg It's a relatively simple device that measures the blood flow in your finger with an infrared sensor. Powered by USB, the device sends measurements to the XO via the AC/DC sensor interface (audio jack). Using a Measure variant with a heart beat detection method, we are able to display the heart rate (as shown in the pic). If you're a developer interested in integrating biofeedback into your application, please email me for more details on how you can get your hands on a few of our peripherals. Otherwise, we are looking for developers who can help us evolve the Measure activity to better suit the lesson plan we have created for the device. The device is not of clinical quality and solely for educational purposes. We are definitely interested in feedback on our direction. In the short-term, it would be interesting to develop a gui where you could structure a family tree (even extending it to branches for relatives) and allow kids to record measurements for various family members. This could potentially evolve into other health education efforts with a wiki backbone to support health wellness. Please send me your feedback and your interest! Thanks, Tom Boonsiri -- OLPC GoldenState (tom.boons...@gmail.com) ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Right now this device works primarily with the XO-1, taking advantage of the AC/DC conversion going on in the XO's audio-in port. But if the gain were tweaked a bit more it could work with other audio cards. The fact that it is XO-1 Hardware specific means that packaging for different architectures isn't a problem in the short run, correct? On Wed, Apr 8, 2009 at 7:56 AM, Peter Robinson pbrobin...@gmail.com wrote: Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). So the sensors are the ones that can get plugged into the audio input/output on the XO? Is this custom to the XO or could be conceivably be implemented/used on other audio cards? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
There's generally no issue with hardware specific packages in distros (there certainly isn't an issue in Fedora), from the quick read I had of the ticket it looks more like the turtle activity didn't work on the non XO hardware. I presume that's because it couldn't load the specific libraries. Generally you would put the hardware specific bits in either a separate package from the app or a sub-package so that for devices where the hardware isn't present it doesn't need to be installed. This though would require the app to be able to detect the whether drivers/plugins are present or not and deal with it. There would be no issue installing them by default as long as it doesn't disturb other sound cards that aren't supported. Peter BTW the idea of the hardware sensors is very cool. Is there somewhere you can see what sensors are available for the XO and buy them? Right now this device works primarily with the XO-1, taking advantage of the AC/DC conversion going on in the XO's audio-in port. But if the gain were tweaked a bit more it could work with other audio cards. The fact that it is XO-1 Hardware specific means that packaging for different architectures isn't a problem in the short run, correct? On Wed, Apr 8, 2009 at 7:56 AM, Peter Robinson pbrobin...@gmail.com wrote: Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). So the sensors are the ones that can get plugged into the audio input/output on the XO? Is this custom to the XO or could be conceivably be implemented/used on other audio cards? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Peter, In the ticket, I was trying to express my ignorance of how to proceed, but not suggest that the distros haven't dealt with these sorts of issues in the past. There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. The other is a means within the Sugar bundling system to include binaries for multiple architectures. I actually had written a work-around for the former, but I remain ignorant about the details of how to best handle the latter. (At one point, Sascha had helped me include a script that would build the appropriate binaries at install time, but that solution depends upon a build environment be installed, which is not the default for most OLPC systems. Oops.) Regarding available sensors, Arjun describes some on the Measure page in the OLPC wiki http://wiki.laptop.org/go/Measure There are also many people working on USB sensor input devices that would be great to support in general. thanks. -walter On Wed, Apr 8, 2009 at 8:22 AM, Peter Robinson pbrobin...@gmail.com wrote: There's generally no issue with hardware specific packages in distros (there certainly isn't an issue in Fedora), from the quick read I had of the ticket it looks more like the turtle activity didn't work on the non XO hardware. I presume that's because it couldn't load the specific libraries. Generally you would put the hardware specific bits in either a separate package from the app or a sub-package so that for devices where the hardware isn't present it doesn't need to be installed. This though would require the app to be able to detect the whether drivers/plugins are present or not and deal with it. There would be no issue installing them by default as long as it doesn't disturb other sound cards that aren't supported. Peter BTW the idea of the hardware sensors is very cool. Is there somewhere you can see what sensors are available for the XO and buy them? Right now this device works primarily with the XO-1, taking advantage of the AC/DC conversion going on in the XO's audio-in port. But if the gain were tweaked a bit more it could work with other audio cards. The fact that it is XO-1 Hardware specific means that packaging for different architectures isn't a problem in the short run, correct? On Wed, Apr 8, 2009 at 7:56 AM, Peter Robinson pbrobin...@gmail.com wrote: Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). So the sensors are the ones that can get plugged into the audio input/output on the XO? Is this custom to the XO or could be conceivably be implemented/used on other audio cards? Peter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. That would need to be accepted upstream by the alsa project, and then distros will automatically get the changes when they are part of a release. The other is a means within the Sugar bundling system to include binaries for multiple architectures. I actually had written a work-around for the former, but I remain ignorant about the details of how to best handle the latter. (At one point, Sascha had helped me include a script that would build the appropriate binaries at install time, but that solution depends upon a build environment be installed, which is not the default for most OLPC systems. Oops.) That would be just a packaging procedure. In the case of Fedora it would be just the arch dependant rpms as opposed to using a activity .xo file which I believe are arch independent. Unless I've missed something here. Regarding available sensors, Arjun describes some on the Measure page in the OLPC wiki Thanks! http://wiki.laptop.org/go/Measure There are also many people working on USB sensor input devices that would be great to support in general. In fedora at least from a driver perspective it would land in Fedora as soon as the upstream kernel has the drivers. I'm not sure whether there is a defined api for accessing those sort sensors on linux. If there was I would presume as the hardware is added that TA/measure would automatically get support for the hardware as its added, if there's not I presume there would need to be individual support added for each device. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). So the sensors are the ones that can get plugged into the audio input/output on the XO? Is this custom to the XO or could be conceivably be implemented/used on other audio cards? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Hi In a related note Kristianpaulhttp://co.sugarlabs.org/wiki/index.php?title=Usuario:Kristianpaulaction=editredlink=1of Sugarlabs .co is testing measure in Soas (with arjun's help) in an effort to adapt it to all kinds of hardware. http://co.sugarlabs.org/go/Sobre_Measure Rafael Ortiz On Wed, Apr 8, 2009 at 7:40 AM, Peter Robinson pbrobin...@gmail.com wrote: There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. That would need to be accepted upstream by the alsa project, and then distros will automatically get the changes when they are part of a release. The other is a means within the Sugar bundling system to include binaries for multiple architectures. I actually had written a work-around for the former, but I remain ignorant about the details of how to best handle the latter. (At one point, Sascha had helped me include a script that would build the appropriate binaries at install time, but that solution depends upon a build environment be installed, which is not the default for most OLPC systems. Oops.) That would be just a packaging procedure. In the case of Fedora it would be just the arch dependant rpms as opposed to using a activity .xo file which I believe are arch independent. Unless I've missed something here. Regarding available sensors, Arjun describes some on the Measure page in the OLPC wiki Thanks! http://wiki.laptop.org/go/Measure There are also many people working on USB sensor input devices that would be great to support in general. In fedora at least from a driver perspective it would land in Fedora as soon as the upstream kernel has the drivers. I'm not sure whether there is a defined api for accessing those sort sensors on linux. If there was I would presume as the hardware is added that TA/measure would automatically get support for the hardware as its added, if there's not I presume there would need to be individual support added for each device. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Walter Bender wrote: Peter, In the ticket, I was trying to express my ignorance of how to proceed, but not suggest that the distros haven't dealt with these sorts of issues in the past. There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. The other is a means within the Sugar bundling system to include binaries for multiple architectures. I What binary drivers are you talking about? -- Richard Smith rich...@laptop.org One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). I'm guessing below, because I can't find the source of the binary driver you are discussing. The bug report doesn't point to it, and it isn't in an obvious place in the OLPC git or the Sugar gitorious. It's not a binary driver, it's just a library implemented in C or C++ rather than Python. This is only novel to the Sugar team -- the vast majority of packages in every Linux distro are already this way. There's already a python-alsaaudio package in Ubuntu: http://packages.ubuntu.com/intrepid/sound/python-alsaaudio If this is the module you're calling, your sugar-measure-activity package just has to mention that as a dependency, and all should be well. If you have your own unique python-alsaaudio module, you'll probably want to merge it with the already-existing one, and fix up Measure so it can call the existing public one. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
