Openmoko Bug #2145: Debian: Reading of accelerometers broken
#2145: Debian: Reading of accelerometers broken --+- Reporter: Defiant | Owner: hardware Type: defect| Status: new Priority: normal| Milestone: Component: hardware |Version: unspecified Severity: normal| Keywords: debian event2 event3 Haspatch: 0 | Blockedby: Estimated:|Patchreview: Blocking:| Reproducible: always --+- Running Debian with Kernel 2.6.24-20081103.git7172ec57-1 I have the following problem reading the accelerometers. -when the device is lying still /dev/input/event2 and 3 is producing output -as soon as the is moved event2 3 are no longer producing any output. -when the device is lying still again the device is producing output again. I tested it with a simple hexdump /dev/input/event2 Some people on #openmoko-debian were able to reproduce this bug. This problem doesn't occur running the Om2008.9 kernel. -- Ticket URL: https://docs.openmoko.org/trac/ticket/2145 docs.openmoko.org http://docs.openmoko.org/trac/ openmoko trac ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Openmoko Bug #2145: Debian: Reading of accelerometers broken
#2145: Debian: Reading of accelerometers broken --+- Reporter: Defiant | Owner: hardware Type: defect| Status: new Priority: normal| Milestone: Component: hardware |Version: unspecified Severity: normal| Keywords: debian event2 event3 Haspatch: 0 | Blockedby: Estimated:|Patchreview: Blocking:| Reproducible: always --+- Changes (by andy): * cc: [EMAIL PROTECTED] (added) Comment: It sounds a great deal like the wrong polarity of threshold interrupt is being selected, ie, interrupt when it's LESS than the threshold rather than more. lis302dl supports both polarities. cc-ing Simon Kagstrom since he wrote the threshold stuff. -- Ticket URL: https://docs.openmoko.org/trac/ticket/2145#comment:1 docs.openmoko.org http://docs.openmoko.org/trac/ openmoko trac ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Openmoko Bug #2145: Debian: Reading of accelerometers broken
#2145: Debian: Reading of accelerometers broken --+- Reporter: Defiant | Owner: hardware Type: defect| Status: new Priority: normal| Milestone: Component: hardware |Version: unspecified Severity: normal| Keywords: debian event2 event3 Haspatch: 0 | Blockedby: Estimated:|Patchreview: Blocking:| Reproducible: always --+- Comment(by andy): Thanks for looking at it Simon, I guess a big difference is that Debian is still on some variant of stable branch. Defiant, have a try of the same thing with the kernel you can find in http://people.openmoko.org/andy the one with andy-tracking in the name, see if it changes the behaviour. These are from today and quite similar to what Simon is testing with. -- Ticket URL: https://docs.openmoko.org/trac/ticket/2145#comment:3 docs.openmoko.org http://docs.openmoko.org/trac/ openmoko trac ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 related power measurement of the GSM modem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Setup: The GSM modem is registered to a network but otherwise idle. The | GTA02 is connected to a PC via USB, the battery is removed and instead | power is supplied by an external power supply. There is a 1 Ohm resistor in | one of the supply lines, the voltage across this resistor is measured. Only 1R is very high for this kind of measurement considering it's sucking |2A, you're dropping 2V here to definitely impact operation of the thing you're measuring -- | been clearly visible. One interesting thing: If the external power supply | limits the current, the GSM modem will perform a reset when trying to | send and there is not enough current available (probably the supply voltage | will drop and causes the reset). I am not sure what happens if the battery | is weak and if this could happen during normal operation. I think this is a very nice idea to get a grip on what this autonomous, current-sucking thing is doing. There's a great isolated Hall-effect integrated solution for current measurement that would enable monitoring at high bandwidth (80kHz) with much reduced impact on the voltage cheaply and simply: http://www.allegromicro.com/en/Products/Part_Numbers/0712/ http://uk.farnell.com/allegro-microsystems/acs712elctr-20a-t/sensor-current-20a-soic8-712/dp/1329624 You just replace your 1R resistor with it and give it 5V, hook the output to your scope. BTW it's a great relief to have someone dealing with the firmware :-) - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkwICwACgkQOjLpvpq7dMrL+gCeIgoxQDYl1m11XOPDa74oe0gz 4mcAn2LG7/O0DGxg04HsybJKC+7wtEg5 =aNms -END PGP SIGNATURE- ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: [sound]: capacitor that act like a high-pass filter and so removes the bass on the headphones jack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | I think I understand. I built one 10 F capacitor into the adapter (at the | mass), so the problem with the headphones should be fixed. I also measured a | 1,59V current at the capacitor when plugged in and silent. Sound is good as | before. | | It's beginning to sound very appealing. I was very disappointed to | discover that my FR is unusable as an MP3 player (and I'm not demanding: | I usually find 64Kb/s Vorbis files good enough for such a use). | | Unfortunately, the internal speaker sounds really bad now (distorted). | So I think i'll remove the silver again and find somebody who can help | me with the soldering... | | Hmm... why does it distort the interal speaker? With the caps the transducer experiences -~1.5V .. +~1.5V worth of deflection down and up; without the caps it experiences 0 .. ~3V worth all up. So it's physically unable to deflect enough linearly I would think. | Would it be possible to add a 10 F capacitor on top of the 1 F one | and connect it (in parallel) using your magic silver thingy (that | I know nothing about), so as to avoid the soldering? It is electrically possible but all of this is in a metal can with very constrained height since the case and then battery sits on top of it. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkwIlsACgkQOjLpvpq7dMrCVACeOrX8++KJayN08dN6Om92zMYb SZQAnAxC7S6ngZgZlmZI0p6VNcVwXzrL =FQfU -END PGP SIGNATURE- ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 related power measurement of the GSM modem
Andy Green wrote: There's a great isolated Hall-effect integrated solution for current measurement that would enable monitoring at high bandwidth (80kHz) with much reduced impact on the voltage cheaply and simply: http://www.allegromicro.com/en/Products/Part_Numbers/0712/ Marvellous ! This chip gets a place of honor on my shopping list. Thanks a lot ! - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: [sound]: capacitor that act like a high-pass filter and so removes the bass on the headphones jack
Am Sa 29. November 2008 schrieb Andy Green: Somebody in the thread at some point said: | I think I understand. I built one 10 F capacitor into the adapter (at the | mass), so the problem with the headphones should be fixed. I also measured a | 1,59V current at the capacitor when plugged in and silent. Sound is good as | before. | | It's beginning to sound very appealing. I was very disappointed to | discover that my FR is unusable as an MP3 player (and I'm not demanding: | I usually find 64Kb/s Vorbis files good enough for such a use). | | Unfortunately, the internal speaker sounds really bad now (distorted). | So I think i'll remove the silver again and find somebody who can help | me with the soldering... | | Hmm... why does it distort the interal speaker? With the caps the transducer experiences -~1.5V .. +~1.5V worth of deflection down and up; without the caps it experiences 0 .. ~3V worth all up. So it's physically unable to deflect enough linearly I would think. Please note the internal speaker isn't connected via the 1uF capacitors. See SPK LOCATION:41XX page6 schematics GTA02. So shorting them will not directly cause a different DC-offset situation on internal speaker, and shouldn't make any trouble for it. A short to GND when applying the silver-varnish on the other hand might cause the distortion you have heard. I won't recommend shorting the DC-blocking capacitors. A decent rework/fix comprises finding a place for 2 100uF, and then connecting these in parallel to the 1uF, preferably by by shielded two-wires-cable. If these big capacitors are located outside can, I strongly suggest to place a ferrite bead directly on the hole where the cable enters he can, to block RF from entering the can (homebrew buzzissue). BTW: be aware you easily may destroy headsets or speakers by applying DC for prolonged periods of time. Strongly deprecated. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Openmoko Bug #1542: gps does not get fix
#1542: gps does not get fix -+-- Reporter: emdete|Owner: hardware Type: defect| Status: closed Priority: high |Milestone: Component: hardware | Version: Severity: blocker | Resolution: fixed Keywords: gps antenna fix internal | Haspatch: 0 Blockedby:|Estimated: Patchreview:| Blocking: Reproducible:| -+-- Changes (by mwester): * status: new = closed * haspatch: = 0 * resolution: = fixed Comment: The software fix for this problem on the GTA01 has been committed some time ago, and should be present in all current distro's GTA01 kernels. The fix is a port of the GTA02 solution, with the same behavior(notably, that the SD clock is slowed down significantly whenever the GPS is powered up, and the SD clock is stopped entirely except during actual reading or writing of SD card data). Significant improvements in time-to-first-fix are evident, including the ability to obtain fixes in locations where this was previously not possible. Marking this ticket as fixed -- re-open this if the problem persists (after verifying that the GTA01 patch is present in the kernel, of course). -- Ticket URL: https://docs.openmoko.org/trac/ticket/1542#comment:27 docs.openmoko.org http://docs.openmoko.org/trac/ openmoko trac ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
