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 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
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 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
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 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
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 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
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 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
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- ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
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 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
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 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep