test
test ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
test 2
test ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: test 2
El Dimarts 07 Juliol 2015, a les 11:26:57, Matteo Zaffonato va escriure: Got it too, it was received on Spam folder as the first one. Tanks for your message, I Just noticed that my messages sent on the other account go to the spam folder only when I send them to a mailing list. Thanks for the confirmation -- jluis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test
Il 07/07/2015 10:47, Jose Luis Perez Diez ha scritto: test ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Got it, it was received on Spam folder. Matteo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test 2
Il 07/07/2015 11:11, Jose Luis Perez Diez ha scritto: test ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Got it too, it was received on Spam folder as the first one. Matteo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-2012.01-rc2, please test
On Fri, Mar 02, 2012 at 11:55:27AM +0100, Martin Jansa wrote: Hi, on FSOSHRCON'11 we decided that we should do first official release. We expected to ship it in January, but everybody was quite busy so only now we have something to call at least rc1. Of course there are still some bugs, some are even already known, but please let us know what is blocking this release and what can be fixed in next one. To do that please test latest staging images+feeds. See http://www.shr-project.org/trac/wiki/Stabilizing http://www.shr-project.org/trac/wiki/StagingTests for details how to test them. Hi, shr-2012.01-rc2 is in http://build.shr-project.org/shr-core-staging/035/ this time with images :) -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
shr-2012.01-rc1, please test
Hi, on FSOSHRCON'11 we decided that we should do first official release. We expected to ship it in January, but everybody was quite busy so only now we have something to call at least rc1. Of course there are still some bugs, some are even already known, but please let us know what is blocking this release and what can be fixed in next one. To do that please test latest staging images+feeds. See http://www.shr-project.org/trac/wiki/Stabilizing http://www.shr-project.org/trac/wiki/StagingTests for details how to test them. I've started image rebuild for staging 032, but I'm leaving for 5 days tomorrow at 4AM and I guess they won't be finished in time to close 032 for easier testing.. that's why I'm sending this announcement now. If there is at least few test reports tonight I'll merge staging feeds up to 031 to public feed so we get more users using it. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-2012.01-rc1, please test
On Friday 02 March 2012 11:55:27 Martin Jansa wrote: Hi, on FSOSHRCON'11 we decided that we should do first official release. We expected to ship it in January, but everybody was quite busy so only now we have something to call at least rc1. Of course there are still some bugs, some are even already known, but please let us know what is blocking this release and what can be fixed in next one. To do that please test latest staging images+feeds. See http://www.shr-project.org/trac/wiki/Stabilizing http://www.shr-project.org/trac/wiki/StagingTests for details how to test them. I've started image rebuild for staging 032, but I'm leaving for 5 days tomorrow at 4AM and I guess they won't be finished in time to close 032 for easier testing.. that's why I'm sending this announcement now. If there is at least few test reports tonight I'll merge staging feeds up to 031 to public feed so we get more users using it. Cheers, I can't see any rootfs to test. Am I looking in the wrong place? From the docs linked above it looks like it should be in: http://build.shr-project.org/shr-core-staging/031/images/om-gta02/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-2012.01-rc1, please test
On Fri, Mar 2, 2012 at 18:25, Al Johnson openm...@mazikeen.demon.co.uk wrote: I can't see any rootfs to test. Am I looking in the wrong place? From the docs linked above it looks like it should be in: http://build.shr-project.org/shr-core-staging/031/images/om-gta02/ Not every staging feed has whole image rebuilt. You need to download and install some older image and upgrade to 031 after that. Instead of manually navigating through the directories, you can use download wizard on http://build.shr-project.org/ to automatically find latest image available (requires JavaScript). -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-2012.01-rc1, please test
On Friday 02 March 2012 18:34:20 Sebastian Krzyszkowiak wrote: On Fri, Mar 2, 2012 at 18:25, Al Johnson openm...@mazikeen.demon.co.uk wrote: I can't see any rootfs to test. Am I looking in the wrong place? From the docs linked above it looks like it should be in: http://build.shr-project.org/shr-core-staging/031/images/om-gta02/ Not every staging feed has whole image rebuilt. You need to download and install some older image and upgrade to 031 after that. Instead of manually navigating through the directories, you can use download wizard on http://build.shr-project.org/ to automatically find latest image available (requires JavaScript). Just to make sure I've got the right end of the stick, and won't be adding results for the wrong thing: rootfs from 030 kernel and qi from 031 fix the feeds at 031 using: sed -i 's#/shr-.*/ipk/#/shr-core-staging/031/ipk/#g;' /etc/opkg/*-feed.conf update/upgrade and start testing ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-2012.01-rc1, please test
On 02.03.2012 19:51, Al Johnson wrote: Just to make sure I've got the right end of the stick, and won't be adding results for the wrong thing: rootfs from 030 kernel and qi from 031 fix the feeds at 031 using: sed -i 's#/shr-.*/ipk/#/shr-core-staging/031/ipk/#g;' /etc/opkg/*-feed.conf update/upgrade and start testing Hi, that's the correct way. I did it the same way: downloaded the gta04 image from 030 then upgraded to 031/latest (which is the same at the moment). Cheers, Lukas signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
call echo service for test of audio calls
Hello, I'm testing my new SHR installation, but the question perhaps is valid for all FR distributions: Is there some call-echo-service like Skype offers, i.e. one does a call to the service number, listen the greeting message, says something of 10-15 secs, and the service after this echoes back what it was listening? If it would be free of charge and in Germany, even better :-) Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: call echo service for test of audio calls
Matthias Apitz g...@unixarea.de writes: If it would be free of charge and in Germany, even better :-) I used to call my asterisk voice mail for such tests. Even had a fancy DTMF menu for different test scenarios. Unfortunately my operator (Saunalahti Nettipuhelin) is no longer offering SIP. Maybe you can use some non-free voice mail service? ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] GTA04A3 Early Adopter boards in final production test stage
Am 28.09.2011 um 09:56 schrieb Dr. H. Nikolaus Schaller: Am 28.09.2011 um 09:20 schrieb Timo Juhani Lindfors: Dr. H. Nikolaus Schaller h...@goldelico.com writes: http://www.youtube.com/watch?v=gCjM48BqfYo BTW, we plan to put the tester software under GPL (which is not forbidden for OSX application software). Here it is, if someone is interested in. Maybe to write a GNUstep port and to do a GUI translation to English... http://download.goldelico.com/gta04/20110926-GTA04A3-HW-Tester/GTA04Tester.zip ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04A3 Early Adopter boards in final production test stage
Dr. H. Nikolaus Schaller h...@goldelico.com writes: http://www.youtube.com/watch?v=gCjM48BqfYo Interesting! However, I couldn't help noticing: seeing the non-free OS X (?) here makes me bit nervous. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04A3 Early Adopter boards in final production test stage
Am 28.09.2011 um 09:20 schrieb Timo Juhani Lindfors: Dr. H. Nikolaus Schaller h...@goldelico.com writes: http://www.youtube.com/watch?v=gCjM48BqfYo Interesting! However, I couldn't help noticing: seeing the non-free OS X (?) here makes me bit nervous. Well, we can simply not expect that we can make everything free and with free tools only. The production machines use ... something that starts with a big W. The chips we use, are designed with some unknown non-free VHDL tools. The courier service finally delivering the components or units uses some servers for the tracking information we don't have control about. My attitude is: don't be fundamentalistic with freedom but focus on free and open software (and information exchange). The goal of the GTA04 is to support free and open software better as any other portable hardware you can get. And this is independent from using non-free tools during design and production. If we rule out to work with any non-free tool, we can't even start. So we use non-free tools where it is the best decision to bring forward the project. If the project becomes successfull, we can think about replacing more and more of those non-free components and tools. But this is IMHO the second step. BTW, we plan to put the tester software under GPL (which is not forbidden for OSX application software). BR, Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA04A3 Early Adopter boards in final production test stage
Hi all, the production of the remaining pre-ordered GTA04 Early Adopter boards is now running and we have received the first three of them. So we were able to attach them to the new GTA04-Tester, that has been set up. Since a Video shows more than we can describe - here is one showing the Tester and how the boards are tested: http://www.youtube.com/watch?v=gCjM48BqfYo Enjoy! All 3 boards have passed the test and the others are expected to arrive this week. Let's cross fingers that they also pass the tests and that there is no severe issue in the areas that are not tested... Nikolaus Schaller Plot: The test equipment consists of some old MacMini (PowerPC based) with USB cable, a SD card with the hardware-validation Linux kernel and a battery. Testing starts by inserting the SD card, adding a wire to hold the battery, connect USB and finally insert the Battery. Soon after doing this, U-Boot switches on the Power LED to red/yellow/green. The test software thinks that there is no connection on USB, since the kernel is still booting and setting up the musb driver and the ethernet gadget. After a while, the first ping to the board becomes successful, and the detailled tests start. Tests include reading the IMEI from the UMTS modem module, configuring WLAN and scanning for the MacMini's WLAN and Bluetooth transmitters. Finally, almost all tests are passed, except the one for the Camera module - which is not plugged in. Please note, that this test is not really complete. Amongst the areas not tested are: Display, Audio, UMTS transmission, Vibracall, GPS sensitivity. Typical Test Report === Report from GTA04 Tester - 2011-09-26 21:21:05 +0200 BMA180: Ok 201,-22,-3742 BMP085: Ok 77152 GTM601: Ok GTM601-IMEI:Ok 354154040021088 HMC5883L: Ok ITG3200:Ok 6168 6168 6168 6168 LIS302: Ok M24LR64:Ok OV9655: Nok Si47xx: Ok TCA6507:Ok TPS61050: Ok TSC2007:Ok 0,0,0,0,0,0,1228,1507,106,65535 USB:Ok W2CBW003-BT:Ok W2CBW003-BT-scan: Ok 00:23:12:3D:07:A2 MacMini W2CBW003-WLAN: Ok W2CBW003-WLAN-libertas: Ok W2CBW003-WLAN-scan: Ok ESSID:MacMini W2SG0004: Ok $GPGGA,06.046,0,00,,,M,0.0,M,,*52 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] GTA04A3 Early Adopter boards in final production test stage
Nikolaus, Since a Video shows more than we can describe - here is one showing the Tester and how the boards are tested: Very interesting video, thanks (as always) for keeping us informed (as always)! Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04A3 test progress
On Sat, 18 Jun 2011 03:25:43 +0200 Christoph Mair m...@chonyota.net wrote: Hi, finally here is a status update on the GTA04A3 board. That's what I've done until now to test it: - attach power, serial console works - boot from sd card (works) - revert I2C-fix from u-boot and kernel - works without: the hardware is ok, the power supply issues are gone. - test switches and LEDs (seems ok) - turn GPS on and off (works, didn't wait for a fix yet) - attach an external GPS antenna (was not recognized, maybe my antenna is broken) - boot debian and lxde (works) - test touch screen (works) - attach an USB cable (gives errors in dmesg, GTA04 is not recognized as USB device, usb host not tested yet) - add driver and firmware for WLAN (chip is recognized, driver seems to be buggy, does not execute commands) - enable bluetooth (without success yet) Enough for today, I will continue tomorrow. Good night, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community So many good news, I hope you will sleep a bit now, 3:25 am is a good time to go to bed! Do you have the GSM chip enabled ? -- Thomas HOCEDEZ thomas.hoce...@free.fr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04A3 test progress
Am 18.06.2011 um 09:40 schrieb Thomas HOCEDEZ: On Sat, 18 Jun 2011 03:25:43 +0200 Christoph Mair m...@chonyota.net wrote: Hi, finally here is a status update on the GTA04A3 board. That's what I've done until now to test it: - attach power, serial console works - boot from sd card (works) - revert I2C-fix from u-boot and kernel - works without: the hardware is ok, the power supply issues are gone. - test switches and LEDs (seems ok) - turn GPS on and off (works, didn't wait for a fix yet) - attach an external GPS antenna (was not recognized, maybe my antenna is broken) - boot debian and lxde (works) - test touch screen (works) - attach an USB cable (gives errors in dmesg, GTA04 is not recognized as USB device, usb host not tested yet) - add driver and firmware for WLAN (chip is recognized, driver seems to be buggy, does not execute commands) - enable bluetooth (without success yet) Enough for today, I will continue tomorrow. Good night, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community So many good news, I hope you will sleep a bit now, 3:25 am is a good time to go to bed! Do you have the GSM chip enabled ? Well, the UMTS modem module is not yet soldered on those two boards we have so far. The reason is that it is a littele easier to test the internal USB port on which the module is hooked up if the module is not connected. And we wanted to reduce the amount of money we would scrap, if the board did fail. But so far it looks good and we finally can add one of those (expensive) UMTS modules. BR, Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA04A3 test progress
Hi, finally here is a status update on the GTA04A3 board. That's what I've done until now to test it: - attach power, serial console works - boot from sd card (works) - revert I2C-fix from u-boot and kernel - works without: the hardware is ok, the power supply issues are gone. - test switches and LEDs (seems ok) - turn GPS on and off (works, didn't wait for a fix yet) - attach an external GPS antenna (was not recognized, maybe my antenna is broken) - boot debian and lxde (works) - test touch screen (works) - attach an USB cable (gives errors in dmesg, GTA04 is not recognized as USB device, usb host not tested yet) - add driver and firmware for WLAN (chip is recognized, driver seems to be buggy, does not execute commands) - enable bluetooth (without success yet) Enough for today, I will continue tomorrow. Good night, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
test-post 00
Apologies if this test-message makes it through to the list and annoys people; I have another message that I've been trying (and failing) to post to the list, and I'm trying to diagnose it ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test-post 00
On Thu, Jun 17, 2010 at 4:01 AM, Joshua Judson Rosen roz...@geekspace.com wrote: Apologies if this test-message makes it through to the list and annoys people; I have another message that I've been trying (and failing) to post to the list, and I'm trying to diagnose it BURN HIM!!! just joking, it works. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko free runner as GPS tracking device for automobiles and Vibration test rig
On Sun, Oct 11, 2009 at 11:30 AM, RANJAN infi...@gmail.com wrote: Hi, Check out the attempt of I and my team of friends: GPS tracking using FR on a CAR: http://www.youtube.com/watch?v=rtS_pU9kyp8feature=channel Vibration measurement and Analysis: http://www.youtube.com/watch?v=p5fUorY2ekMfeature=channel Regards Sriranjan this is really fantastic. do you have any plans to expand its functionality to g-force, lap timing, or acceleration? im really hopping for a version of g-tac for the openmoko!! http://www.apptism.com/apps/g-tac-pro ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Open Moko free runner as GPS tracking device for automobiles and Vibration test rig
Hi, Check out the attempt of I and my team of friends: GPS tracking using FR on a CAR: http://www.youtube.com/watch?v=rtS_pU9kyp8feature=channel Vibration measurement and Analysis: http://www.youtube.com/watch?v=p5fUorY2ekMfeature=channel Regards Sriranjan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko free runner as GPS tracking device for automobiles and Vibration test rig
Awesome dude... I'm inspired !! On Mon, Oct 12, 2009 at 12:00 AM, RANJAN infi...@gmail.com wrote: Hi, Check out the attempt of I and my team of friends: GPS tracking using FR on a CAR: http://www.youtube.com/watch?v=rtS_pU9kyp8feature=channel Vibration measurement and Analysis: http://www.youtube.com/watch?v=p5fUorY2ekMfeature=channel Regards Sriranjan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko free runner as GPS tracking device for automobiles and Vibration test rig
Wov, this is nice? Where's the code, do you use Freerunner to log the data then analyze it later on a desktop? Thanks! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone binary (to test bluetooth headset issues)
I hate for you to waste precious GUI space on a problem that only one person seems to have. If I were you, I would make it a conffile option or something unobtrusive... I'm pretty certain it's a Bluez bug. It happens on my laptop too. I should probably submit a bug report... :P ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone binary (to test bluetooth headset issues)
c_c wrote: well other things when i return to settings page it says speaker and not headphone :) Hmmm. That's not right - will take a look. I have the same issue : when opening the options menu it's always on 'speakers'. I made some tests (well, in fact i listened for 1hour+ of music :) ) ealier today, and it worked flawlessly. I only faced the following issue : if the device goes away (no more batteries, or you shut it down) intone will hang. Otherwise it's getting better everyday, keep on good work :) -- View this message in context: http://n2.nabble.com/Intone-binary-%28to-test-bluetooth-headset-issues%29-tp3307149p3315194.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone binary (to test bluetooth headset issues)
Hi, KaZeR wrote: I only faced the following issue : if the device goes away (no more batteries, or you shut it down) intone will hang. Can you run mplayer in the terminal (with -msglevel global=6) shut down the headphone and send me the errors that mplayer comes up with? Thanks. -- View this message in context: http://n2.nabble.com/Intone-binary-%28to-test-bluetooth-headset-issues%29-tp3307149p3315766.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone binary (to test bluetooth headset issues)
Hi. Unfortunately, if you're blocking duplicate keypresses within anything less than a second, it's pointless. No-one else seems to have this problem, and for me, they are typically .6-.8 seconds apart. Maybe you could make it some kind of 'hidden feature' since you don't want it eating up GUI space, but at least for me, it's a critically necessary feature. Maybe a cmdline option or conf-file option? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone binary (to test bluetooth headset issues)
Hi, The Digital Pioneer wrote: No-one else seems to have this problem, and for me, they are typically .6-.8 seconds apart. Ok. Will move this to a gui settings option. And back to 1 sec between keypresses. Wasn't sure if this was more common or not. But, I agree, it doesn't seem to be. -- View this message in context: http://n2.nabble.com/Intone-binary-%28to-test-bluetooth-headset-issues%29-tp3307149p3323959.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone binary (to test bluetooth headset issues)
Hi, von_fritz wrote: Hello, sorry i' am not subscribed to the openmoko-community-list. i will answer in this thread, if for you it's not a problem. well using your binary. 1. Headset model = B-speech calypso 2. Keys working or not = volume + and - OK; skip FW and BW OK 3. Keys support/scan codes = well skip FW/BW gives scan code but volume +/- works but no scancode : keyname-Keycode-171, Keycode-171 for skip forward keyname-Keycode-173, Keycode-173 for skip backward volume +/- works but when pressing gives no scancode last button = call button when pressing plays stops and gives: time diff- 1248388650.616782 when repressing call button : plays continues with messagges : keyname-Keycode-172, Keycode-172 Simple mixer control 'PCM',0 Capabilities: volume Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 255 Front Left: 215 [84%] [-20.00dB] Front Right: 215 [84%] [-20.00dB] Simple mixer control 'Bass',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 15 Mono: 0 [0%] Simple mixer control 'Treble',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 15 Mono: 0 [0%] time diff- 62.448643 well other things when i return to settings page it says speaker and not headphone :) When i am in settings page pressing skip FW/BW its non working, pressing volume+/- works that's it thanks for your great work ;) well other things when i return to settings page it says speaker and not headphone :) Hmmm. That's not right - will take a look. Actually, the focus is with the playlist/album art views. Moving to any other page currently prevents the bluetooth keys from working. How should it be - should the keys be listened for on all pages? BTW - In you case the volume keys are internal to the headset. Thanks for the report - will add it to the other thread too! -- View this message in context: http://n2.nabble.com/Intone-binary-%28to-test-bluetooth-headset-issues%29-tp3307149p3313309.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Intone binary (to test bluetooth headset issues)
Hi, I thought it would be best if I could keep all the bluetooth headset and control keys (AVRCP) issues in one thread for future reference. I'm posting a binary that :- 1. rejects a second play/pause press (happens on at least one headset automatically) if it happens with 150ms of the first one 2. prints out when it rejects the second play/pause key press 3. is more tolerant to the bluetooth blips 4. should recover automatically from broken connections with bluetooth headsets and play from speakers 5. Automatically insmod's 'uinput' for the AVRCP keypress detection 6. Switches on bluetooth on selecting bluetooth streaming It also fixes the Pause not working after pressing back key (5 secs from beginning of song) pointed out by Staley, Daniel L. I request all users who have any feedback to mention the following :- 1. headset model 2. whether the keys works or not 3. any peculiarities (like the Plantronics Voyager 855 that sends 2 presses for play/pause) 4. any other keys that need support (vol +/- etc) and their scan codes. To get the scan code run intone from the terminal. It will print a message like keyname-Keycode-171,Keycode-171. Please post the message here. 5. anything else that you feel is relevant and helpful for debugging etc Thanks http://n2.nabble.com/file/n3307149/intone intone -- View this message in context: http://n2.nabble.com/Intone-binary-%28to-test-bluetooth-headset-issues%29-tp3307149p3307149.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stress test of my Freerunner
I attached my code. As said, it isn't much and not very user-friendly. However, I was surprised how few code is needed to get the idea working. storeLocation.py: This script is called on the FR to store the current coordinates to locations.dat E.g. storeLocation.py -t My Home -d This is where I live since 5 years Please modify http://myserver.org/; to your needs. sendLocations.sh: All locations stored in locations.dat can be send to the server with the small sendLocations.sh script. I used the http-get method since there was no urllib module in SHR. add.py: On the server side, add.py receives the coordinates as cgi script and stores the information to locations.dat. (I should change the name, since the content is different to locations.dat on the FR...) diary.kml: This is also a cgi script written in Python which creates the kml output from the content of locations.dat. Have fun :-) Sven Hi Sven, is it OK to use your code and GPL it? I started building a little GUI for what you have done as a travel diary sounds like a pretty good idea to me. You can see what I have done so far here: http://git.senfdax.de/?p=travel-diary;a=summary Currently it does nothing else than requesting GPS and diesplaying the fields. bitbake recipe to follow as soon as it really does something. Anyone interested in making an icon? Cheers, Christian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stress test of my Freerunner
Hey Christian, On Friday 12 June 2009 13:56:32 Christian Rüb wrote: is it OK to use your code and GPL it? The license text would be longer than my source code, thus I didn't add anything ;-) GPL2 or 3 is fine for me, thanks for asking... I started building a little GUI for what you have done as a travel diary sounds like a pretty good idea to me. You can see what I have done so far here: http://git.senfdax.de/?p=travel-diary;a=summary Currently it does nothing else than requesting GPS and diesplaying the fields. bitbake recipe to follow as soon as it really does something. Great to hear that my code is somehow useful. Sven ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stress test of my Freerunner
On Sunday June 7 2009 16:18:48 Yogiz wrote:
Thanks for the impressions. I really like the GPS diary idea. Perhaps
you should release it to the public? As to alarms, try ffalarms (opkg
install ffalarms).
I attached my code. As said, it isn't much and not very user-friendly. However,
I was surprised how few code is needed to get the idea working.
storeLocation.py:
This script is called on the FR to store the current coordinates to
locations.dat
E.g. storeLocation.py -t My Home -d This is where I live since 5 years
Please modify http://myserver.org/; to your needs.
sendLocations.sh:
All locations stored in locations.dat can be send to the server with the small
sendLocations.sh script. I used the http-get method since there was no urllib
module in SHR.
add.py:
On the server side, add.py receives the coordinates as cgi script and stores
the information to locations.dat. (I should change the name, since the content
is different to locations.dat on the FR...)
diary.kml:
This is also a cgi script written in Python which creates the kml output from
the content of locations.dat.
Have fun :-)
Sven
diary.kml
Description: application/vnd.google-earth.kml
#! /usr/bin/env python
# -*- coding: utf-8 -*-
import cgi
import cgitb
cgitb.enable()
print(Content-Type: text/html) # Header-Info
print() # Empty line needed
form = cgi.FieldStorage()
if not (form.has_key(latitude) and form.has_key(longitude) and form.has_key(date) and form.has_key(title)):
print H1Error/H1
print Please fill in the fields.
else:
f = open('locations.dat', 'a')
if (form.has_key(details)):
f.write(form[date].value+ | + form[latitude].value+ |+form[longitude].value+|+form[title].value+|+ form[details].value+\n )
else:
f.write(form[date].value+ | + form[latitude].value+ |+form[longitude].value+|+form[title].value+|+\n )
f.close()
print OK
sendLocations.sh
Description: application/shellscript
#! /usr/bin/env python
# -*- coding: utf-8 -*-
# Logging
import logging
import sys
mainlogger = logging.getLogger()
console = logging.StreamHandler(sys.stdout)
console_formatter = logging.Formatter(%(name)s - %(levelname)s - %(message)s)
console.setFormatter(console_formatter)
mainlogger.addHandler(console)
logger = logging.getLogger()
logger.setLevel(logging.DEBUG)
import optparse
import datetime
import dbus
#import urllib
class MyOptionParser(optparse.OptionParser):
def __init__(self):
optparse.OptionParser.__init__(self,usage: %prog -t title [-d \more details\ | ... ])
self.add_option(-t,
--title,
action=store,
type=string,
dest=title,
help=Title of this location)
self.add_option(-d,
--details,
action=store,
type=string,
dest=details,
help=Detailed information of this location)
self.add_option(--longitude,
action=store,
type=string,
dest=longitude,
help=Set longitude manually)
self.add_option(--latitude,
action=store,
type=string,
dest=latitude,
help=Set latitude manually)
self.add_option(--date,
action=store,
type=string,
dest=date,
help=Set date manually)
self.set_defaults(date=datetime.date.today().isoformat())
def getCoordinates():
system_bus = dbus.SystemBus()
gps_object = system_bus.get_object('org.freesmartphone.ogpsd', '/org/freedesktop/Gypsy')
gps_interface = dbus.Interface(gps_object, dbus_interface='org.freesmartphone.Resource')
gps_interface.Enable()
gps_interface = dbus.Interface(gps_object, dbus_interface='org.freedesktop.Gypsy.Position')
position=gps_interface.GetPosition()
print(position)
# gps_interface = dbus.Interface(gps_object, dbus_interface='org.freesmartphone.Resource')
# gps_interface.Disable()
if (position[0]==0):
logger.warning(No GPS data)
return None, None
return str(position[2]), str(position[3])
def saveLocation(latitude, longitude, date, title, details):
url=http://myserver.org/add.py?;
url=url+date=+date
url=url+latitude=+latitude
url=url+longitude=+longitude
url=url+title=+UrlEncode(title)
if (details!=None):
url=url+details=+UrlEncode(details)
print(url)
f=open(locations.dat,a)
f.write(url+\n)
# SHR doesn't have the urlib module, therefore I used the code snippet from
# http://blog.affien.com/archives/2005/06/25/python-url-encoding/comment-page-1/
HexCharacters = 0123456789abcdef
def UrlEncode(s):
r = ''
for c in s:
o = ord(c)
if (o = 48 and o = 57) or \
(o = 97 and o = 122) or \
(o = 65 and o = 90) or \
o == 36 or o == 45 or o == 95 or \
o == 46 or o == 43 or o == 33 or \
o == 42 or o == 39 or o == 40 or \
o == 41 or o == 44:
r += c
else:
r += '%' + CleanCharHex(c)
return r
def CleanCharHex(c):
o = ord(c)
r = HexCharacters[o / 16]
r += HexCharacters[o % 16]
return r
if __name__ == __main__:
parser= MyOptionParser()
options, args =
Stress test of my Freerunner
As you already noticed from my last mail (Visit at Openmoko), I was traveling through Taiwan. I didn't want to blame anyone, but share my feelings with people that are also thrilled by this project. Nevertheless as several people already mentioned, we have an open phone! and there is a future! I use my Freerunner for several weeks as my daily phone now (started after the buzz was fixed by Daniel, thanks). However, the last two weeks I stretched my FR to the limit and it did it well: Few days before I started traveling Taiwan, I decided to make some GPS based diary for my friends at home. Thanks to the very easy API of FSO, I was able to write a basic application in Python within three evenings. The applications sends the current coordinates and some text to my server, where a KML file is created which can be downloaded by my friends. At the airport, I bought a cheap Taiwan SIM card and I started to transmit my position via GPRS (which also worked out-of-the-box). Furthermore, the timezone changed automagically based on GSM (my old Sony Ericsson wasn't able to do so). I had a lot of fun during the last weeks tracking my travel. Of course, I had some problems but I could solve all of them more or less. E.g. the SHR alarm application doesn't worked. So I did the alarm the bash way: sleep 28800 aplay alarm.wav :-) With this solution, the phone couldn't suspend. Luckily, the wall charger has Taiwan connections below the European adaptor :-) Furthermore, I was that adventurous to make an opkg upgrade during the travel :-) Thereafter, I couldn't suspend after I started GPRS. Annoying, but not a serious problem. I love my FR Sven P.S.: Now I start to fill some bug reports :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stress test of my Freerunner
Thanks for the impressions. I really like the GPS diary idea. Perhaps you should release it to the public? As to alarms, try ffalarms (opkg install ffalarms). Yogiz On Sun, 7 Jun 2009 21:55:37 +0800 Sven Klomp s...@klomp.de wrote: As you already noticed from my last mail (Visit at Openmoko), I was traveling through Taiwan. I didn't want to blame anyone, but share my feelings with people that are also thrilled by this project. Nevertheless as several people already mentioned, we have an open phone! and there is a future! I use my Freerunner for several weeks as my daily phone now (started after the buzz was fixed by Daniel, thanks). However, the last two weeks I stretched my FR to the limit and it did it well: Few days before I started traveling Taiwan, I decided to make some GPS based diary for my friends at home. Thanks to the very easy API of FSO, I was able to write a basic application in Python within three evenings. The applications sends the current coordinates and some text to my server, where a KML file is created which can be downloaded by my friends. At the airport, I bought a cheap Taiwan SIM card and I started to transmit my position via GPRS (which also worked out-of-the-box). Furthermore, the timezone changed automagically based on GSM (my old Sony Ericsson wasn't able to do so). I had a lot of fun during the last weeks tracking my travel. Of course, I had some problems but I could solve all of them more or less. E.g. the SHR alarm application doesn't worked. So I did the alarm the bash way: sleep 28800 aplay alarm.wav :-) With this solution, the phone couldn't suspend. Luckily, the wall charger has Taiwan connections below the European adaptor :-) Furthermore, I was that adventurous to make an opkg upgrade during the travel :-) Thereafter, I couldn't suspend after I started GPRS. Annoying, but not a serious problem. I love my FR Sven P.S.: Now I start to fill some bug reports :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stress test of my Freerunner
Thanks Sven, Sorry I was not there on Monday when you visited the office. I left TPE the previous friday. Glad to hear you love you FR, keep up the good work and best of luck on your project. Sven Klomp wrote: As you already noticed from my last mail (Visit at Openmoko), I was traveling through Taiwan. I didn't want to blame anyone, but share my feelings with people that are also thrilled by this project. Nevertheless as several people already mentioned, we have an open phone! and there is a future! I use my Freerunner for several weeks as my daily phone now (started after the buzz was fixed by Daniel, thanks). However, the last two weeks I stretched my FR to the limit and it did it well: Few days before I started traveling Taiwan, I decided to make some GPS based diary for my friends at home. Thanks to the very easy API of FSO, I was able to write a basic application in Python within three evenings. The applications sends the current coordinates and some text to my server, where a KML file is created which can be downloaded by my friends. At the airport, I bought a cheap Taiwan SIM card and I started to transmit my position via GPRS (which also worked out-of-the-box). Furthermore, the timezone changed automagically based on GSM (my old Sony Ericsson wasn't able to do so). I had a lot of fun during the last weeks tracking my travel. Of course, I had some problems but I could solve all of them more or less. E.g. the SHR alarm application doesn't worked. So I did the alarm the bash way: sleep 28800 aplay alarm.wav :-) With this solution, the phone couldn't suspend. Luckily, the wall charger has Taiwan connections below the European adaptor :-) Furthermore, I was that adventurous to make an opkg upgrade during the travel :-) Thereafter, I couldn't suspend after I started GPRS. Annoying, but not a serious problem. I love my FR Sven P.S.: Now I start to fill some bug reports :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stress test of my Freerunner
Great, this is encouraging! Please share your blogging script, I'm sure there are people interested in it! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stress test of my Freerunner!
Great post, good vibrations! Thanks for sharing... and keep the bug reports coming! Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
On Fri, Mar 27, 2009 at 05:21:59AM +0800, Qingyou Meng wrote: Because display and GPS chip may be powered on for a long while, I choose to test them here. [snip] Here is the results: 1. when GPS chip is powered off, test brightness vs. battery current: * brightness = 100%: battery current ~= 203 mA * brightness = 75%: battery current ~= 153 mA * brightness = 50%: battery current ~= 116 mA * brightness = 25%: battery current ~= 101 mA * brightness = 0%: battery current ~= 95 mA See also http://lists.openmoko.org/pipermail/openmoko-kernel/2008-October/005542.html I.e. you're not turning the display off by just setting the backlight brightness to 0. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[Debian] Save 8 mA. Apmd considered harmful? (Was: test result of battery current against display brightness and GPS power mode)
On Fri, Mar 27, 2009 at 01:56:26AM +0100, Rask Ingemann Lambertsen wrote:
You must have done something wrong. I frequently test power comsumption
and I get 54 mA on a fully charged battery, dropping slowly as the battery
discharges[1] and nearly 20 hours battery life.
FWIW, I test with this command on a Debian installation:
sleep 120 cat
/sys/class/power_supply/battery/{status,current_now,voltage_now,capacity}
[1] It's supposed to be the other way around - current increasing as the
battery discharges - but there's a current leak somewhere. It was down to 46
mA not too long ago with a kernel from the andy-tracking branch.
This mysterious current leak seems to be fixed by not running apmd!
# /etc/init.d/apmd stop
# update-rc.d -f apmd remove
# update-rc.d apmd stop 20 0 1 2 3 4 5 6 .
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
You can activate almost all kind of logging, just go to settings-logging and from the bottom menu there you can select Categories where you can activate all kind of logging. Franky On Mon, Apr 20, 2009 at 5:09 PM, Fabio Locati fabioloc...@gmail.com wrote: @Franky: is there a way to see what phone is doing? if yes, I can do it and send here the results... who does this sounds? On Mon, Apr 20, 2009 at 5:04 PM, Radek Polak pson...@seznam.cz wrote: Franky Van Liedekerke wrote: I don't know, I don't have a SIM card with which to check the status (I have a subscription, not a credit-based card). But it was to show that the dialer does support the * and # characters. And I believe these are normal calls, they just get interpreted by the phone company that then returns a special crafted message with the requested info. Hi, i am able to show my credit by calling *22# My image is this one [1], but i dont think that the image is different from any other images. It's probably operator specific or some other factor is involved. It is possible to enable modem commands logging and this could be used to debug the problem. Radek [1] http://activationrecord.net/radekp/openmoko/qtmoko/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Rome, RM, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
these logs are saved in /var/log? On Tue, Apr 21, 2009 at 9:29 AM, Franky Van Liedekerke liede...@telenet.be wrote: You can activate almost all kind of logging, just go to settings-logging and from the bottom menu there you can select Categories where you can activate all kind of logging. Franky On Mon, Apr 20, 2009 at 5:09 PM, Fabio Locati fabioloc...@gmail.com wrote: @Franky: is there a way to see what phone is doing? if yes, I can do it and send here the results... who does this sounds? On Mon, Apr 20, 2009 at 5:04 PM, Radek Polak pson...@seznam.cz wrote: Franky Van Liedekerke wrote: I don't know, I don't have a SIM card with which to check the status (I have a subscription, not a credit-based card). But it was to show that the dialer does support the * and # characters. And I believe these are normal calls, they just get interpreted by the phone company that then returns a special crafted message with the requested info. Hi, i am able to show my credit by calling *22# My image is this one [1], but i dont think that the image is different from any other images. It's probably operator specific or some other factor is involved. It is possible to enable modem commands logging and this could be used to debug the problem. Radek [1] http://activationrecord.net/radekp/openmoko/qtmoko/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Rome, RM, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
Use logread to see the logs, but yes, they are saved there as well. But since the file rotates rather quickly, you won't save a lot of data. Franky On Tue, Apr 21, 2009 at 2:35 PM, Fabio Locati fabioloc...@gmail.com wrote: these logs are saved in /var/log? On Tue, Apr 21, 2009 at 9:29 AM, Franky Van Liedekerke liede...@telenet.be wrote: You can activate almost all kind of logging, just go to settings-logging and from the bottom menu there you can select Categories where you can activate all kind of logging. Franky On Mon, Apr 20, 2009 at 5:09 PM, Fabio Locati fabioloc...@gmail.com wrote: @Franky: is there a way to see what phone is doing? if yes, I can do it and send here the results... who does this sounds? On Mon, Apr 20, 2009 at 5:04 PM, Radek Polak pson...@seznam.cz wrote: Franky Van Liedekerke wrote: I don't know, I don't have a SIM card with which to check the status (I have a subscription, not a credit-based card). But it was to show that the dialer does support the * and # characters. And I believe these are normal calls, they just get interpreted by the phone company that then returns a special crafted message with the requested info. Hi, i am able to show my credit by calling *22# My image is this one [1], but i dont think that the image is different from any other images. It's probably operator specific or some other factor is involved. It is possible to enable modem commands logging and this could be used to debug the problem. Radek [1] http://activationrecord.net/radekp/openmoko/qtmoko/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Rome, RM, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
*123# Apr 21 15:53:30 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : T : ^Z Apr 21 15:53:30 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : W : Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : W : OK Apr 21 15:53:31 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:53:31 om-gta02 user.notice Qtopia: AtChat : T : ATD*123# Apr 21 15:53:31 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:31 om-gta02 user.notice Qtopia: AtChat : F : OK Apr 21 15:53:34 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:34 om-gta02 user.notice Qtopia: AtChat : ? : OK *123*3# Apr 21 15:54:39 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:54:39 om-gta02 user.notice Qtopia: AtChat : T : ^Z Apr 21 15:54:40 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:40 om-gta02 user.notice Qtopia: AtChat : W : Apr 21 15:54:40 om-gta02 user.notice Qtopia: AtChat : W : OK Apr 21 15:54:41 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:54:41 om-gta02 user.notice Qtopia: AtChat : T : ATD*123*3# Apr 21 15:54:41 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:41 om-gta02 user.notice Qtopia: AtChat : F : OK Apr 21 15:54:44 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:44 om-gta02 user.notice Qtopia: AtChat : ? : OK I have no clue about what this means... I hope someone has... Please tell me if the report is missing info or is wrong. On Tue, Apr 21, 2009 at 2:52 PM, Franky Van Liedekerke liede...@telenet.be wrote: Use logread to see the logs, but yes, they are saved there as well. But since the file rotates rather quickly, you won't save a lot of data. Franky On Tue, Apr 21, 2009 at 2:35 PM, Fabio Locati fabioloc...@gmail.com wrote: these logs are saved in /var/log? On Tue, Apr 21, 2009 at 9:29 AM, Franky Van Liedekerke liede...@telenet.be wrote: You can activate almost all kind of logging, just go to settings-logging and from the bottom menu there you can select Categories where you can activate all kind of logging. Franky On Mon, Apr 20, 2009 at 5:09 PM, Fabio Locati fabioloc...@gmail.com wrote: @Franky: is there a way to see what phone is doing? if yes, I can do it and send here the results... who does this sounds? On Mon, Apr 20, 2009 at 5:04 PM, Radek Polak pson...@seznam.cz wrote: Franky Van Liedekerke wrote: I don't know, I don't have a SIM card with which to check the status (I have a subscription, not a credit-based card). But it was to show that the dialer does support the * and # characters. And I believe these are normal calls, they just get interpreted by the phone company that then returns a special crafted message with the requested info. Hi, i am able to show my credit by calling *22# My image is this one [1], but i dont think that the image is different from any other images. It's probably operator specific or some other factor is involved. It is possible to enable modem commands logging and this could be used to debug the problem. Radek [1] http://activationrecord.net/radekp/openmoko/qtmoko/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Rome, RM, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com
Re: test QtEI
On Tue, 21 Apr 2009 15:56:20 +0200 Fabio Locati fabioloc...@gmail.com wrote: *123# Apr 21 15:53:30 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : T : ^Z Apr 21 15:53:30 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : W : Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : W : OK Apr 21 15:53:31 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:53:31 om-gta02 user.notice Qtopia: AtChat : T : ATD*123# Apr 21 15:53:31 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:31 om-gta02 user.notice Qtopia: AtChat : F : OK Apr 21 15:53:34 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:34 om-gta02 user.notice Qtopia: AtChat : ? : OK *123*3# Apr 21 15:54:39 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:54:39 om-gta02 user.notice Qtopia: AtChat : T : ^Z Apr 21 15:54:40 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:40 om-gta02 user.notice Qtopia: AtChat : W : Apr 21 15:54:40 om-gta02 user.notice Qtopia: AtChat : W : OK Apr 21 15:54:41 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:54:41 om-gta02 user.notice Qtopia: AtChat : T : ATD*123*3# Apr 21 15:54:41 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:41 om-gta02 user.notice Qtopia: AtChat : F : OK Apr 21 15:54:44 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:44 om-gta02 user.notice Qtopia: AtChat : ? : OK I have no clue about what this means... I hope someone has... Please tell me if the report is missing info or is wrong. no clue either ... are you sure these are the correct numbers? Which qtextended version are you using (where did you download it, etc ...)? Is it based on a 2.6.24 kernel or are you using a 2.6.28 kernel (like in my install script)? Franky ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
I am using a 2.6.24 kernel and your image from the 3rd of april On Tue, Apr 21, 2009 at 10:01 PM, Franky Van Liedekerke liede...@telenet.be wrote: On Tue, 21 Apr 2009 15:56:20 +0200 Fabio Locati fabioloc...@gmail.com wrote: *123# Apr 21 15:53:30 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : T : ^Z Apr 21 15:53:30 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : W : Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : W : OK Apr 21 15:53:31 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:53:31 om-gta02 user.notice Qtopia: AtChat : T : ATD*123# Apr 21 15:53:31 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:31 om-gta02 user.notice Qtopia: AtChat : F : OK Apr 21 15:53:34 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:34 om-gta02 user.notice Qtopia: AtChat : ? : OK *123*3# Apr 21 15:54:39 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:54:39 om-gta02 user.notice Qtopia: AtChat : T : ^Z Apr 21 15:54:40 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:40 om-gta02 user.notice Qtopia: AtChat : W : Apr 21 15:54:40 om-gta02 user.notice Qtopia: AtChat : W : OK Apr 21 15:54:41 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:54:41 om-gta02 user.notice Qtopia: AtChat : T : ATD*123*3# Apr 21 15:54:41 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:41 om-gta02 user.notice Qtopia: AtChat : F : OK Apr 21 15:54:44 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:44 om-gta02 user.notice Qtopia: AtChat : ? : OK I have no clue about what this means... I hope someone has... Please tell me if the report is missing info or is wrong. no clue either ... are you sure these are the correct numbers? Which qtextended version are you using (where did you download it, etc ...)? Is it based on a 2.6.24 kernel or are you using a 2.6.28 kernel (like in my install script)? Franky ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
Then I recommend you first upgrade to a 2.6.28 based kernel (if you can live without bluetooth) and the latest release (or at least the latest release). For a 2.6.28 kernel, see these comments at the top of my install script. I use this kernel: http://users.telenet.be/liedekef/uImage-2.6.28-andy-tracking+gitr6+9c4451ff31b937a478f3d3eabef30b71cbe12b12-r3-om-gta02.bin and the fso-console-image from http://downloads.openmoko.org/distro/unstable/daily/om-gta02/20090404/ Franky On Tue, 21 Apr 2009 23:25:33 +0200 Fabio Locati fabioloc...@gmail.com wrote: I am using a 2.6.24 kernel and your image from the 3rd of april On Tue, Apr 21, 2009 at 10:01 PM, Franky Van Liedekerke liede...@telenet.be wrote: On Tue, 21 Apr 2009 15:56:20 +0200 Fabio Locati fabioloc...@gmail.com wrote: *123# Apr 21 15:53:30 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : T : ^Z Apr 21 15:53:30 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : W : Apr 21 15:53:30 om-gta02 user.notice Qtopia: AtChat : W : OK Apr 21 15:53:31 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:53:31 om-gta02 user.notice Qtopia: AtChat : T : ATD*123# Apr 21 15:53:31 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:31 om-gta02 user.notice Qtopia: AtChat : F : OK Apr 21 15:53:34 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:53:34 om-gta02 user.notice Qtopia: AtChat : ? : OK *123*3# Apr 21 15:54:39 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:54:39 om-gta02 user.notice Qtopia: AtChat : T : ^Z Apr 21 15:54:40 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:40 om-gta02 user.notice Qtopia: AtChat : W : Apr 21 15:54:40 om-gta02 user.notice Qtopia: AtChat : W : OK Apr 21 15:54:41 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::write() Apr 21 15:54:41 om-gta02 user.notice Qtopia: AtChat : T : ATD*123*3# Apr 21 15:54:41 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:41 om-gta02 user.notice Qtopia: AtChat : F : OK Apr 21 15:54:44 om-gta02 user.notice Qtopia: Mux : QGsm0710MultiplexerPrivate::read() Apr 21 15:54:44 om-gta02 user.notice Qtopia: AtChat : ? : OK I have no clue about what this means... I hope someone has... Please tell me if the report is missing info or is wrong. no clue either ... are you sure these are the correct numbers? Which qtextended version are you using (where did you download it, etc ...)? Is it based on a 2.6.24 kernel or are you using a 2.6.28 kernel (like in my install script)? Franky ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
Yes it does, I tried eg. the code for call divert status and it works just fine. All the ones mentioned at http://www.geckobeach.com/cellular/secrets/gsmcodes.php should work just fine (well, maybe not all functionality is implemented, but it should work). Maybe try the 2.6.28 version I provide (it is of course based upon code from Karadog). Franky On Mon, Apr 20, 2009 at 4:31 AM, Tuan TRINH openmoko...@gmail.com wrote: Hi,As far as I know, qt-extended currently does not support * , # chars in dial string. On Sun, Apr 19, 2009 at 1:57 AM, Fabio Locati fabioloc...@gmail.comwrote: I'm using: Qt-Extended: 4.4.3 build by liho...@dashi-x02 on Apr 3 2009 Kernel: 2.6.24 compiled by bu...@barbie Thankyou for your fast answer :) On Sat, Apr 18, 2009 at 8:40 PM, Joseph Reeves iknowjos...@gmail.com wrote: What OS are you using? These codes work fine for me (OM2009 Vodafone UK SIM). Cheers, Joseph 2009/4/18 Fabio Locati fabioloc...@gmail.com: My Phone operator (Wind Italy) have some numbers (ie: *123#,*123*3#) to check various things (credit, sms left and so on). After you make a call, should appear a sort of advice with the data you requested. This advice appears afetr I make a call (in this case, Wind update me about my credit), but does not appear if I call the specific numbers. How can I debug it to make a better report? -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Milan, MI, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
@Franky: the numbers that Wind give me are not in the page you linked... Is this meaning that is normal that they do not work? btw: these calls are normal calls or are data calls or something else? Thank you for your time and your attention :) On Mon, Apr 20, 2009 at 10:12 AM, Franky Van Liedekerke liede...@telenet.be wrote: Yes it does, I tried eg. the code for call divert status and it works just fine. All the ones mentioned at http://www.geckobeach.com/cellular/secrets/gsmcodes.php should work just fine (well, maybe not all functionality is implemented, but it should work). Maybe try the 2.6.28 version I provide (it is of course based upon code from Karadog). Franky On Mon, Apr 20, 2009 at 4:31 AM, Tuan TRINH openmoko...@gmail.com wrote: Hi, As far as I know, qt-extended currently does not support * , # chars in dial string. On Sun, Apr 19, 2009 at 1:57 AM, Fabio Locati fabioloc...@gmail.com wrote: I'm using: Qt-Extended: 4.4.3 build by liho...@dashi-x02 on Apr 3 2009 Kernel: 2.6.24 compiled by bu...@barbie Thankyou for your fast answer :) On Sat, Apr 18, 2009 at 8:40 PM, Joseph Reeves iknowjos...@gmail.com wrote: What OS are you using? These codes work fine for me (OM2009 Vodafone UK SIM). Cheers, Joseph 2009/4/18 Fabio Locati fabioloc...@gmail.com: My Phone operator (Wind Italy) have some numbers (ie: *123#,*123*3#) to check various things (credit, sms left and so on). After you make a call, should appear a sort of advice with the data you requested. This advice appears afetr I make a call (in this case, Wind update me about my credit), but does not appear if I call the specific numbers. How can I debug it to make a better report? -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Milan, MI, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
I don't know, I don't have a SIM card with which to check the status (I have a subscription, not a credit-based card). But it was to show that the dialer does support the * and # characters. And I believe these are normal calls, they just get interpreted by the phone company that then returns a special crafted message with the requested info. Franky On Mon, Apr 20, 2009 at 3:20 PM, Fabio Locati fabioloc...@gmail.com wrote: @Franky: the numbers that Wind give me are not in the page you linked... Is this meaning that is normal that they do not work? btw: these calls are normal calls or are data calls or something else? Thank you for your time and your attention :) On Mon, Apr 20, 2009 at 10:12 AM, Franky Van Liedekerke liede...@telenet.be wrote: Yes it does, I tried eg. the code for call divert status and it works just fine. All the ones mentioned at http://www.geckobeach.com/cellular/secrets/gsmcodes.php should work just fine (well, maybe not all functionality is implemented, but it should work). Maybe try the 2.6.28 version I provide (it is of course based upon code from Karadog). Franky On Mon, Apr 20, 2009 at 4:31 AM, Tuan TRINH openmoko...@gmail.com wrote: Hi, As far as I know, qt-extended currently does not support * , # chars in dial string. On Sun, Apr 19, 2009 at 1:57 AM, Fabio Locati fabioloc...@gmail.com wrote: I'm using: Qt-Extended: 4.4.3 build by liho...@dashi-x02 on Apr 3 2009 Kernel: 2.6.24 compiled by bu...@barbie Thankyou for your fast answer :) On Sat, Apr 18, 2009 at 8:40 PM, Joseph Reeves iknowjos...@gmail.com wrote: What OS are you using? These codes work fine for me (OM2009 Vodafone UK SIM). Cheers, Joseph 2009/4/18 Fabio Locati fabioloc...@gmail.com: My Phone operator (Wind Italy) have some numbers (ie: *123#,*123*3#) to check various things (credit, sms left and so on). After you make a call, should appear a sort of advice with the data you requested. This advice appears afetr I make a call (in this case, Wind update me about my credit), but does not appear if I call the specific numbers. How can I debug it to make a better report? -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Milan, MI, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
Franky Van Liedekerke wrote: I don't know, I don't have a SIM card with which to check the status (I have a subscription, not a credit-based card). But it was to show that the dialer does support the * and # characters. And I believe these are normal calls, they just get interpreted by the phone company that then returns a special crafted message with the requested info. Hi, i am able to show my credit by calling *22# My image is this one [1], but i dont think that the image is different from any other images. It's probably operator specific or some other factor is involved. It is possible to enable modem commands logging and this could be used to debug the problem. Radek [1] http://activationrecord.net/radekp/openmoko/qtmoko/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
@Franky: is there a way to see what phone is doing? if yes, I can do it and send here the results... who does this sounds? On Mon, Apr 20, 2009 at 5:04 PM, Radek Polak pson...@seznam.cz wrote: Franky Van Liedekerke wrote: I don't know, I don't have a SIM card with which to check the status (I have a subscription, not a credit-based card). But it was to show that the dialer does support the * and # characters. And I believe these are normal calls, they just get interpreted by the phone company that then returns a special crafted message with the requested info. Hi, i am able to show my credit by calling *22# My image is this one [1], but i dont think that the image is different from any other images. It's probably operator specific or some other factor is involved. It is possible to enable modem commands logging and this could be used to debug the problem. Radek [1] http://activationrecord.net/radekp/openmoko/qtmoko/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Rome, RM, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
Hi,As far as I know, qt-extended currently does not support * , # chars in dial string. On Sun, Apr 19, 2009 at 1:57 AM, Fabio Locati fabioloc...@gmail.com wrote: I'm using: Qt-Extended: 4.4.3 build by liho...@dashi-x02 on Apr 3 2009 Kernel: 2.6.24 compiled by bu...@barbie Thankyou for your fast answer :) On Sat, Apr 18, 2009 at 8:40 PM, Joseph Reeves iknowjos...@gmail.com wrote: What OS are you using? These codes work fine for me (OM2009 Vodafone UK SIM). Cheers, Joseph 2009/4/18 Fabio Locati fabioloc...@gmail.com: My Phone operator (Wind Italy) have some numbers (ie: *123#,*123*3#) to check various things (credit, sms left and so on). After you make a call, should appear a sort of advice with the data you requested. This advice appears afetr I make a call (in this case, Wind update me about my credit), but does not appear if I call the specific numbers. How can I debug it to make a better report? -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Milan, MI, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
test QtEI
My Phone operator (Wind Italy) have some numbers (ie: *123#,*123*3#) to check various things (credit, sms left and so on). After you make a call, should appear a sort of advice with the data you requested. This advice appears afetr I make a call (in this case, Wind update me about my credit), but does not appear if I call the specific numbers. How can I debug it to make a better report? -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
What OS are you using? These codes work fine for me (OM2009 Vodafone UK SIM). Cheers, Joseph 2009/4/18 Fabio Locati fabioloc...@gmail.com: My Phone operator (Wind Italy) have some numbers (ie: *123#,*123*3#) to check various things (credit, sms left and so on). After you make a call, should appear a sort of advice with the data you requested. This advice appears afetr I make a call (in this case, Wind update me about my credit), but does not appear if I call the specific numbers. How can I debug it to make a better report? -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test QtEI
I'm using: Qt-Extended: 4.4.3 build by liho...@dashi-x02 on Apr 3 2009 Kernel: 2.6.24 compiled by bu...@barbie Thankyou for your fast answer :) On Sat, Apr 18, 2009 at 8:40 PM, Joseph Reeves iknowjos...@gmail.com wrote: What OS are you using? These codes work fine for me (OM2009 Vodafone UK SIM). Cheers, Joseph 2009/4/18 Fabio Locati fabioloc...@gmail.com: My Phone operator (Wind Italy) have some numbers (ie: *123#,*123*3#) to check various things (credit, sms left and so on). After you make a call, should appear a sort of advice with the data you requested. This advice appears afetr I make a call (in this case, Wind update me about my credit), but does not appear if I call the specific numbers. How can I debug it to make a better report? -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Milan, MI, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
On Mon, Mar 30, 2009 at 02:41:54PM +0200, Richard Kralovic wrote:
Rask Ingemann Lambertsen wrote:
On Sat, Mar 28, 2009 at 07:32:24PM +0100, Richard Kralovic wrote:
It may be the case that the fixes for the current leak were introduced
in devel branch (linux-openmoko-devel). On kernel 2.6.29-rc3, my tests
show a drop from cca 80mA to cca 47mA.
Do you know which git revision that kernel is? Alternatively, where did
I am using gitr1e257a0e99817a338e3706708ebb5036518e46d8, I compiled it
myself.
OK, I think I've found something. If I boot up Debian with LXDE (with
xscreensaver and pcmanfm uninstalled) and just run the test there, I once in
a while get 53 mA, but usually it's 55 mA. Now I stopped some userspace
stuff:
# /etc/init.d/apmd stop
# /etc/init.d/nodm stop
$ sleep 120 cat
/sys/class/power_supply/battery/{status,current_now,voltage_now,capacity}
Discharging
47250
4151000
100
I.e. 8 mA lost because of something in userspace. :-(
I'm working on CPU frequency scaling support. Slowing the CPU to 100 MHz
and 1.1 V core power supply gives:
$ sleep 120 cat
/sys/class/power_supply/battery/{status,current_now,voltage_now,capacity}
Discharging
39750
4148000
100
:-)
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
On SHR with latest kernel of version 2.6.29-rc3, current is about 62.5 mA, 100% capacity. Here is link to the kernel: http://shr.bearstech.com/shr-unstable/images/om-gta02/uImage-2.6.28-oe1+gitr119778+9c4451ff31b937a478f3d3eabef30b71cbe12b12-r3.1-om-gta02.bin The name mismatches with actual kernel version, it shows 2.6.29-rc3 on boot. Rask Ingemann Lambertsen wrote: On Sat, Mar 28, 2009 at 07:32:24PM +0100, Richard Kralovic wrote: It may be the case that the fixes for the current leak were introduced in devel branch (linux-openmoko-devel). On kernel 2.6.29-rc3, my tests show a drop from cca 80mA to cca 47mA. Do you know which git revision that kernel is? Alternatively, where did I am using gitr1e257a0e99817a338e3706708ebb5036518e46d8, I compiled it myself. Richard you get that kernel from? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/test-result-of-battery-current-against-display-brightness-and-GPS--power-mode-tp2541178p2582277.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
Rask Ingemann Lambertsen wrote: On Sat, Mar 28, 2009 at 07:32:24PM +0100, Richard Kralovic wrote: It may be the case that the fixes for the current leak were introduced in devel branch (linux-openmoko-devel). On kernel 2.6.29-rc3, my tests show a drop from cca 80mA to cca 47mA. Do you know which git revision that kernel is? Alternatively, where did I am using gitr1e257a0e99817a338e3706708ebb5036518e46d8, I compiled it myself. Richard you get that kernel from? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
On Fri, Mar 27, 2009 at 05:21:59AM +0800, Qingyou Meng wrote: To set brightness: write (brightness_percent / 100 * 255) to file /sys/class/backlight/gta02-bl/brightness I think that's why you get so high currents. This # echo /sys/class/backlight/gta02-bl/brightness 0 doesn't do what you hope it does. You should try # echo /sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-regltr.9/glamo3362.0/glamo-spi-gpio.0/spi2.0/state sleep also. A shorthand for that file is /sys/bus/spi/devices/spi2.0/state. When the display isn't blanked, it reads 'normal'. But, IMHO, consider using a higher-level interface (such as freesmartphone.org) to turn off the display instead of trying to find all the places to mess with under /sys yourself. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
Hi,
Thanks a lot!
With echo /sys/bus/spi/devices/spi2.0/state sleep, the current drops
from 82.125 mA to 81.562 mA within 10 minutes. The battery is fully charged
before test.
My kernel:
# uname -a
Linux om-gta02 2.6.28-rc4 #1 PREEMPT Sun Feb 8 19:53:16 CET 2009 armv4tl unknown
Before read your reply, I get nothing by removing SD card, ifdown usb0, power
off backlight.
Here is the new script I used:
#!/bin/bash
# for exit SSH shell, unplug USB
sleep 5
# strange, 1 to power of backlight
echo /sys/class/backlight/gta02-bl/bl_power 1
echo /sys/bus/spi/devices/spi2.0/state sleep
for ((i=0; i20; i++)); do
echo i = $i:
cat /sys/class/power_supply/battery/{current_now,capacity,voltage_now}
sleep 30
done
echo /sys/class/backlight/gta02-bl/bl_power 0
echo /sys/bus/spi/devices/spi2.0/state normal
But comparing to your ~50 mA, 82 mA is still too large :)
Could anybody who has latest SHR installation on GTA02, give a test to verify?
Before start this script, please make sure:
1. `/sys/bus/platform/devices/neo1973-pm-gps.0/pwron` output 0, else you can
echo 0 into it.
2. disable GSM/WIFI/Bluetooth in SHR settings
3. SSH to FR through USB if you haven't connect to it.
4. stop /etc/init.d/xserver-nodm, /etc/init.d/frameworkd
5. killall batget; killall wakerd;
6. start the above script, e.g. `power.sh output_power.txt ` , exit SSH
shell, unplug USB
10 minutes later, you can plug USB and SSH into FR again. If you can't wait for
10 minutes,
modify sleep 30 to sleep 5 or something else.
I'd like to say thank you to Rask Ingemann Lambertsen again :)
On Fri, Mar 27, 2009 at 05:21:59AM +0800, Qingyou Meng wrote:
To set brightness: write (brightness_percent / 100 * 255) to file
/sys/class/backlight/gta02-bl/brightness
I think that's why you get so high currents. This
# echo /sys/class/backlight/gta02-bl/brightness 0
doesn't do what you hope it does. You should try
# echo
/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-regltr.9/glamo3362.0/glamo-spi-gpio.0/spi2.0/state
sleep
also. A shorthand for that file is /sys/bus/spi/devices/spi2.0/state. When
the display isn't blanked, it reads 'normal'.
But, IMHO, consider using a higher-level interface (such as
freesmartphone.org) to turn off the display instead of trying to find all
the places to mess with under /sys yourself.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
--
View this message in context:
http://n2.nabble.com/test-result-of-battery-current-against-display-brightness-and-GPS--power-mode-tp2541178p2549904.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
Hello,
With echo /sys/bus/spi/devices/spi2.0/state sleep, the current drops
from 82.125 mA to 81.562 mA within 10 minutes. The battery is fully charged
before test.
My kernel:
# uname -a
Linux om-gta02 2.6.28-rc4 #1 PREEMPT Sun Feb 8 19:53:16 CET 2009 armv4tl
unknown
It may be the case that the fixes for the current leak were introduced
in devel branch (linux-openmoko-devel). On kernel 2.6.29-rc3, my tests
show a drop from cca 80mA to cca 47mA.
Richard
Before read your reply, I get nothing by removing SD card, ifdown usb0, power
off backlight.
Here is the new script I used:
#!/bin/bash
# for exit SSH shell, unplug USB
sleep 5
# strange, 1 to power of backlight
echo /sys/class/backlight/gta02-bl/bl_power 1
echo /sys/bus/spi/devices/spi2.0/state sleep
for ((i=0; i20; i++)); do
echo i = $i:
cat /sys/class/power_supply/battery/{current_now,capacity,voltage_now}
sleep 30
done
echo /sys/class/backlight/gta02-bl/bl_power 0
echo /sys/bus/spi/devices/spi2.0/state normal
But comparing to your ~50 mA, 82 mA is still too large :)
Could anybody who has latest SHR installation on GTA02, give a test to verify?
Before start this script, please make sure:
1. `/sys/bus/platform/devices/neo1973-pm-gps.0/pwron` output 0, else you can
echo 0 into it.
2. disable GSM/WIFI/Bluetooth in SHR settings
3. SSH to FR through USB if you haven't connect to it.
4. stop /etc/init.d/xserver-nodm, /etc/init.d/frameworkd
5. killall batget; killall wakerd;
6. start the above script, e.g. `power.sh output_power.txt ` , exit SSH
shell, unplug USB
10 minutes later, you can plug USB and SSH into FR again. If you can't wait
for 10 minutes,
modify sleep 30 to sleep 5 or something else.
I'd like to say thank you to Rask Ingemann Lambertsen again :)
On Fri, Mar 27, 2009 at 05:21:59AM +0800, Qingyou Meng wrote:
To set brightness: write (brightness_percent / 100 * 255) to file
/sys/class/backlight/gta02-bl/brightness
I think that's why you get so high currents. This
# echo /sys/class/backlight/gta02-bl/brightness 0
doesn't do what you hope it does. You should try
# echo
/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-regltr.9/glamo3362.0/glamo-spi-gpio.0/spi2.0/state
sleep
also. A shorthand for that file is /sys/bus/spi/devices/spi2.0/state. When
the display isn't blanked, it reads 'normal'.
But, IMHO, consider using a higher-level interface (such as
freesmartphone.org) to turn off the display instead of trying to find all
the places to mess with under /sys yourself.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Simple touching test (maybe someday multitouch test)
Aapo Rantalainen aapo.rantalai...@gmail.com writes: It is gtk program which prints 1) mouse location 2) mouse button press (and its location) 3) mouse button release (and its location) Hmm, isn't this what xev already does? It also supports timestamps. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
Rask Ingemann Lambertsen r...@sygehus.dk writes:
sleep 120 cat
/sys/class/power_supply/battery/{status,current_now,voltage_now,capacity}
Interestingly I get
Discharging
73125
4126000
100
with andy-tracking b8b36e5ec3db
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
On Sat, Mar 28, 2009 at 07:32:24PM +0100, Richard Kralovic wrote: It may be the case that the fixes for the current leak were introduced in devel branch (linux-openmoko-devel). On kernel 2.6.29-rc3, my tests show a drop from cca 80mA to cca 47mA. Do you know which git revision that kernel is? Alternatively, where did you get that kernel from? -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
Thanks for the tip.
My previous test program is written in C. I write a bash script and test again.
GPS, WIFI, bluetooth, GSM, xserve, fso-frameworkd, python, batget are
disabled/closed.
OS suspending is disabled in SHR settings.
With top command, I watch for a while to make sure no process other than top
and dropbear
using more than 0.1% CPU cycles. Then start the script and unplug USB.
#!/bin/bash
for ((i=0; i120; i++)); do
sleep 30
echo i = $i:
cat /sys/class/power_supply/battery/{current_now,capacity,voltage_now}
done
The result is almost same with my previous test, on newly updated SHR:
Within 60 minutes, capacity drops from 100% to 91%, voltage drops from 4.16 V
to 4.06 V,
current increases from 103.5 mA to 104.5 mA,
On Fri, Mar 27, 2009 at 05:21:59AM +0800, Qingyou Meng wrote:
To save power, we set display brightness to 0% by locking screen,
but OS still consumes 95 mA, leaving at most ~10 hours battery life!
You must have done something wrong. I frequently test power comsumption
and I get 54 mA on a fully charged battery, dropping slowly as the battery
discharges[1] and nearly 20 hours battery life.
FWIW, I test with this command on a Debian installation:
sleep 120 cat
/sys/class/power_supply/battery/{status,current_now,voltage_now,capacity}
[1] It's supposed to be the other way around - current increasing as the
battery discharges - but there's a current leak somewhere. It was down to 46
mA not too long ago with a kernel from the andy-tracking branch.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
--
View this message in context:
http://n2.nabble.com/test-result-of-battery-current-against-display-brightness-and-GPS--power-mode-tp2541178p2544244.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
test result of battery current against display brightness and GPS power mode
Because display and GPS chip may be powered on for a long while, I
choose to test them here.
Phone is GTA02v5. Distribution is latest SHR unstable, with almost 0% CPU load.
No devices(WIFI, GSM, etc) opened before this test. Battery capacity
is about 88%.
My test method is, for example: set display background light to 100%,
then get battery current every 5 seconds for a while...
To power on GPS chip: write 1 to file
/sys/bus/platform/devices/neo1973-pm-gps.0/pwron.
To set brightness: write (brightness_percent / 100 * 255) to file
/sys/class/backlight/gta02-bl/brightness
To get current battery power: read file
/sys/class/power_supply/battery/current_now.
- It seems kernel update this file every 30 seconds
- the output unit is uA.
To enable/activate FixNow sleep mode: write UBX binary messages
CFG-FXN and CFG-RXM to /dev/ttySAC1.
- when activate, write dummy packet and RXM-POSREQ message:
{ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xB5,
0x62, 0x02, 0x40, 0x00, 0x00, 0x42, 0xC8 }
Here is the results:
1. when GPS chip is powered off, test brightness vs. battery current:
* brightness = 100%: battery current ~= 203 mA
* brightness = 75%: battery current ~= 153 mA
* brightness = 50%: battery current ~= 116 mA
* brightness = 25%: battery current ~= 101 mA
* brightness = 0%: battery current ~= 95 mA
2. when brightness is 0%, test GPS power state vs. battery current:
* GPS normal power mode: battery current ~= about 144 mA
* GPS FixNow sleep mode: battery current ~= about 97 mA when it goes to sleep
* GPS FixNow sleep mode: battery current ~= about 146 mA when it is waken up
From test #1, (assume battery voltage is constant) we can see:
1) the naked OS with almost zero CPU load and 0% brightness consumes ~95 mA.
2) brightness greatly affect battery life, 100% brightness consumes ~108 mA
3) comparing to 100% brightness,
25% brightness saves 95% power,
50% brightness saves 80% power,
75% brightness saves 55% power
From test #2, we can see:
1) GPS chip consumes about 50 mA when run in normal mode
2) GPS chip consumes near 2 mA when it goes to FixNow sleep
I've been testing FixNow for a while. Now I doubt whether it is useful
for phone users, because:
1) to save power, we can't frequently wake up FixNow from sleep,
because on each wakeup it tries getting fixes for a while then goes to
sleep (off).
2) the position data is not accurate just after wakeup, so we have to
poll for a while, if we're lucky enough we get good fix.
I think, FixNow can only be possibly used in this kind of scenario on
Freerunner:
-- For a long trip, we need log position data (say every 3~5 minutes,
I think it's bad to set the frequency less than 1 minute).
A logger sets GPS chip to FixNow mode, frequently wakeup it to get fix.
To save power, we set display brightness to 0% by locking screen,
but OS still consumes 95 mA, leaving at most ~10 hours battery life!
How to utilize FixNow feature?
Can we make the power consumption of naked OS down to tens of mA?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
On Fri, Mar 27, 2009 at 05:21:59AM +0800, Qingyou Meng wrote:
To save power, we set display brightness to 0% by locking screen,
but OS still consumes 95 mA, leaving at most ~10 hours battery life!
You must have done something wrong. I frequently test power comsumption
and I get 54 mA on a fully charged battery, dropping slowly as the battery
discharges[1] and nearly 20 hours battery life.
FWIW, I test with this command on a Debian installation:
sleep 120 cat
/sys/class/power_supply/battery/{status,current_now,voltage_now,capacity}
[1] It's supposed to be the other way around - current increasing as the
battery discharges - but there's a current leak somewhere. It was down to 46
mA not too long ago with a kernel from the andy-tracking branch.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Simple touching test (maybe someday multitouch test)
Hi, I made first simple application to test touchscreen. It doesn't give me much hope about multitouching, but maybe we can discuss better if we have something. http://cc.oulu.fi/~rantalai/freerunner/touching/ It is gtk program which prints 1) mouse location 2) mouse button press (and its location) 3) mouse button release (and its location) Compiling for Moko: . /usr/local/openmoko/arm/environment-setup make Compiling for Computer: comment out 'CC = arm-angstrom-linux-gnueabi-gcc' on Makefile make I made these test with OM2008.12. If you have time check what your distribution says. Usage: ssh -X r...@moko Case A) [ using computers screen and mouse ] ./touching_test Move mousepointer to window, press button down, move pointer, release button. Terminal output: Pointer moving at (17, 11) Button pressed at (17, 11) Pointer moving at (18, 11) Pointer moving at (19, 11) Pointer moving at (20, 11) Pointer moving at (29, 11) Pointer moving at (43, 11) Pointer moving at (51, 11) Pointer moving at (69, 11) Pointer moving at (89, 11) Pointer moving at (99, 13) Pointer moving at (109, 13) Button released at (113, 13) Pointer moving at (112, 13) Pointer moving at (112, 12) Case B) [ using touchscreen ] DISPLAY=:0 ./touching_test Put stylus somewhere, move it, release it. Terminal output: Pointer moving at (113, 101) Button pressed at (113, 101) Pointer moving at (112, 102) Button released at (436, 103) Case C) [ touchscreen with two stylus] DISPLAY=:0 ./touching_test Put 1st stylus somewhere in top left (and do not release it) Terminal output Pointer moving at (37, 20) Button pressed at (37, 20) Pointer moving at (42, 26) (Start all subcases 1st stylus is in top left) Subcase 1) Put 2nd stylus somewhere in bottom right Terminal output NOTHING Subcase 2) Put 2nd stylus anywhere and move it, release it, put it again, move etc. Terminal output NOTHING Subcase 3) Put 2nd stylus somewhere in bottom right. Release 1st stylus Terminal output NOTHING Release 2nd stylus Terminal output Button released at (454, 438) Subcase 4) Put 2nd stylus somewhere in bottom right Release both in ~sametime Terminal output Button released at (216, 363) midpoint Case B was something which breaks my plans how to implement multitouch. (It doesn't give any messages when dragged) btw: If this doesn't work with GTK, can it work some other way? (Xlib, Qt) -Aapo Rantalainen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] omnewrotate 0.5.2 test package
Hi, It runs fine on 2008.12. Thanks ! Greetings, Steven Rui Miguel Silva Seabra wrote: Could someone with 2008.12 please check if the package at http://files.1407.org/openmoko/rotate/omnewrotate_0.5.2-r0_armv4t.ipk solves issue #4 [1]? If so, I'd be willing to release 0.5.3 fixing it since it isn't yet really using libframeworkd-glib... [1] http://code.google.com/p/omnewrotate/issues/detail?id=4 -- P'tang! Today is Setting Orange, the 68th day of The Aftermath in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-2008.12--omnewrotate-0.5.2-test-package-tp1815566p2018656.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] omnewrotate 0.5.2 test package
Rui Miguel Silva Seabra schrieb: Could someone with 2008.12 please check if the package at http://files.1407.org/openmoko/rotate/omnewrotate_0.5.2-r0_armv4t.ipk solves issue #4 [1]? If so, I'd be willing to release 0.5.3 fixing it since it isn't yet really using libframeworkd-glib... [1] http://code.google.com/p/omnewrotate/issues/detail?id=4 Works here :-) -Marc ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] omnewrotate 0.5.2 test package
On Fri, Dec 26, 2008 at 01:43:42AM +, Rui Miguel Silva Seabra wrote: Could someone with 2008.12 please check if the package at http://files.1407.org/openmoko/rotate/omnewrotate_0.5.2-r0_armv4t.ipk solves issue #4 [1]? If so, I'd be willing to release 0.5.3 fixing it since it isn't yet really using libframeworkd-glib... [1] http://code.google.com/p/omnewrotate/issues/detail?id=4 Thanks for all the reports! :) Rui -- Pzat! Today is Setting Orange, the 68th day of The Aftermath in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[2008.12] omnewrotate 0.5.2 test package
Could someone with 2008.12 please check if the package at http://files.1407.org/openmoko/rotate/omnewrotate_0.5.2-r0_armv4t.ipk solves issue #4 [1]? If so, I'd be willing to release 0.5.3 fixing it since it isn't yet really using libframeworkd-glib... [1] http://code.google.com/p/omnewrotate/issues/detail?id=4 -- P'tang! Today is Setting Orange, the 68th day of The Aftermath in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] omnewrotate 0.5.2 test package
Rui Miguel Silva Seabra wrote: Could someone with 2008.12 please check if the package at http://files.1407.org/openmoko/rotate/omnewrotate_0.5.2-r0_armv4t.ipk solves issue #4 [1]? If so, I'd be willing to release 0.5.3 fixing it since it isn't yet really using libframeworkd-glib... [1] http://code.google.com/p/omnewrotate/issues/detail?id=4 Seems to install fine for me. I'm running 2008.12. r...@om-gta02:~# opkg install /tmp/omnewrotate_0.5.2-r0_armv4t.ipk Installing omnewrotate (0.5.2-r0) to root... Configuring omnewrotate Also, running omnewrotate from the command line or icon works as expected - in other words, awesomely. ;-) Mark C. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
test prog from the ewl-book
Hi,
i have installed enlightenment with the easy_e17.sh script from
http://omicron.homeip.net/projects/#easy_e17.sh ,
first i can't compile notification and screenshot (i skipped these)
then i want to compile a little program i have from the ewl book
#include stdio.h
#include Ewl.h
void destroy_cb(Ewl_Widget *w, void *event, void *data) {
ewl_widget_destroy(w);
ewl_main_quit();
}
int main(int argc, char ** argv) {
Ewl_Widget *win = NULL;
if (!ewl_init(argc, argv)) {
printf(Unable to init ewl\n);
return 1;
}
win = ewl_window_new();
ewl_window_title_set(EWL_WINDOW(win), EWL Window);
ewl_window_name_set(EWL_WINDOW(win), EWL_WINDOW);
ewl_window_class_set(EWL_WINDOW(win), EWLWindow);
ewl_object_size_request(EWL_OBJECT(win), 200, 100);
ewl_callback_append(win, EWL_CALLBACK_DELETE_WINDOW,
destroy_cb, NULL);
ewl_widget_show(win);
ewl_main();
return 0;
}
i compiled the code with
gcc main.c -I/opt/e17/include/ewl -I/opt/e17/include/
-I/opt/e17/include/eina-0 -I/opt/e17/include/eina-0/eina
-L/opt/e17/lib/ewl
then i get following errors
/tmp/ccs04jss.o: In function `destroy_cb':
main.c:(.text+0xd): undefined reference to `ewl_widget_destroy'
main.c:(.text+0x12): undefined reference to `ewl_main_quit'
/tmp/ccs04jss.o: In function `main':
main.c:(.text+0x3b): undefined reference to `ewl_init'
main.c:(.text+0x5c): undefined reference to `ewl_window_new'
main.c:(.text+0x72): undefined reference to
`ewl_window_title_set'
main.c:(.text+0x85): undefined reference to
`ewl_window_name_set'
main.c:(.text+0x98): undefined reference to
`ewl_window_class_set'
main.c:(.text+0xb3): undefined reference to
`ewl_object_size_request'
main.c:(.text+0xb8): undefined reference to
`EWL_CALLBACK_DELETE_WINDOW'
main.c:(.text+0xd7): undefined reference to
`ewl_callback_append'
main.c:(.text+0xe2): undefined reference to `ewl_widget_show'
main.c:(.text+0xe7): undefined reference to `ewl_main'
collect2: ld gab 1 als Ende-Status zurück
hope you can help me
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: gsmhandset state file to test
David Samblas wrote: Hi there on of our colleges[1] of the spanish list has provided us with an gsmhanset state file that solves low volume on call reciver , I have barelly tested it alone with a phone en each ear :). I will test it further along the day and post the results, any one else willing to try is wellcome to do it. from neo or ssh console cd /usr/share/openmoko/scenarios/ mv gsmhandset.state gsmhandset.state.original wget http://n2.nabble.com/attachment/1129707/0/gsmhandset.state [1]The original post http://n2.nabble.com/-Fwd%3A-eco-y-audio--tc1129707ef1958.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community People aren't having any problems hearing me with this state file but I can't hear anything on the already quiet speaker. -Shawn ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gsmhandset state file to test
On Thu, Oct 2, 2008 at 11:04 AM, Shawn prjktdtnt Thompson [EMAIL PROTECTED] wrote: David Samblas wrote: Hi there on of our colleges[1] of the spanish list has provided us with an gsmhanset state file that solves low volume on call reciver , I have barelly tested it alone with a phone en each ear :). I will test it further along the day and post the results, any one else willing to try is wellcome to do it. from neo or ssh console cd /usr/share/openmoko/scenarios/ mv gsmhandset.state gsmhandset.state.original wget http://n2.nabble.com/attachment/1129707/0/gsmhandset.state [1]The original post http://n2.nabble.com/-Fwd%3A-eco-y-audio--tc1129707ef1958.html I been using this for last couple of days. definatley makes a big improvment. call from my side seems fine and other person could hear me clearly. although there was a constant buzz. the buzz is quiet and sounds a bit like signal interference. thanks for posting. azmodie http://www.thelinuxsociety.org.uk -- Due to the speed of light being faster than the speed of sound people often look bright until they speak ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
gsmhandset state file to test
Hi there on of our colleges[1] of the spanish list has provided us with an gsmhanset state file that solves low volume on call reciver , I have barelly tested it alone with a phone en each ear :). I will test it further along the day and post the results, any one else willing to try is wellcome to do it. from neo or ssh console cd /usr/share/openmoko/scenarios/ mv gsmhandset.state gsmhandset.state.original wget http://n2.nabble.com/attachment/1129707/0/gsmhandset.state [1]The original post http://n2.nabble.com/-Fwd%3A-eco-y-audio--tc1129707ef1958.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner CAD Files - IGES ans STEP formats availalbe - Who wants to test them?
Am Donnerstag, den 21.08.2008, 13:55 +0200 schrieb Lothar Behrens: Hi, just a note: I knew about another CAD software, that will convert IGES or ProE format and is Open Source. See this link for more information: http://brlcad.org/ Hi, I do currently convert these iges files into g files that could be read directly by mged of the BRL-CAD package. If someone is interested, I could upload a tgz file to anywhere if the conversion is ready. The CAD package also was compileable without any problems on my Debian Etch (PPC) Regards Lothar ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner CAD Files - IGES ans STEP formats availalbe - Who wants to test them?
On Fri, Aug 22, 2008 at 04:52:54PM +0200, Lothar Behrens wrote: Am Donnerstag, den 21.08.2008, 13:55 +0200 schrieb Lothar Behrens: Hi, just a note: I knew about another CAD software, that will convert IGES or ProE format and is Open Source. See this link for more information: http://brlcad.org/ Hi, I do currently convert these iges files into g files that could be read directly by mged of the BRL-CAD package. If someone is interested, I could upload a tgz file to anywhere if the conversion is ready. The CAD package also was compileable without any problems on my Debian Etch (PPC) Regards Lothar I am definitely interested. When I tried to convert them myself, the reference planes were in the files. I am new to brl-cad and wasn't sure if it was possible to take them out if they weren't defined as separate primitives or whatever. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner CAD Files - IGES ans STEP formats availalbe - Who wants to test them?
Lothar Behrens wrote: Am Donnerstag, den 21.08.2008, 13:55 +0200 schrieb Lothar Behrens: Hi, just a note: I knew about another CAD software, that will convert IGES or ProE format and is Open Source. See this link for more information: http://brlcad.org/ Hi, I do currently convert these iges files into g files that could be read directly by mged of the BRL-CAD package. If someone is interested, I could upload a tgz file to anywhere if the conversion is ready. The CAD package also was compileable without any problems on my Debian Etch (PPC) Regards Lothar Hi Lothar, That's very kind of you. I would be happy to host these files on downloads.openmoko. In fact, the only files OM created are the PRO/E files. The IGES and STEP files are community provided. If anyone can provide conversions to any other format we are happy to host them on downloads. If you place the files somewhere temporary and tell me, I will copy them to downloads. Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner CAD Files - IGES ans STEP formats availalbe - Who wants to test them?
Hi, just a note: I knew about another CAD software, that will convert IGES or ProE format and is Open Source. See this link for more information: http://brlcad.org/ Regards Lothar -- Lothar Behrens |Rapid Prototyping ... Heinrich-Scheufelen-Platz 2 |XSLT Codegeneration 73252 Lenningen |www.lollisoft.de ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: GPS rework: Please test and report on software fix prior toattempting any hardware fix
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Thompson Sent: Monday, August 04, 2008 5:03 PM To: community@lists.openmoko.org Subject: Re: GPS rework: Please test and report on software fix prior toattempting any hardware fix Could we get a link to some image files to use for this testing? I'm not quite sure when Andy's fix made it in the kernel. It would also help standardize the tests if we all use the same images. Josh On Mon August 4 2008 7:29:17 pm Michael Shiloh wrote: Before we conclude that the hardware fix is required, we'd really like to gather a lot of statistics from you about the behavior of the software fix. We have been able to test in only a limited number of locations, and a limited number of phones. We'd like to ask you to run some tests and report back the TTFF in each case: 1. Prior to Andy's software fix 1a. Without SD card 1b. With SD card 2. Using Andy's software fix 2a. Without SD card 2b. With SD card Preferably run this test in multiple locations. Results should be reported on a wiki page, which should include your location (so we can assess other influences e.g. satellite elevation and weather conditions) Thanks, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: GPS rework: Please test and report on software fix priorto attempting any hardware fix
A wiki wont do. A proper test proceedure and test report is called for. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Shiloh Sent: Monday, August 04, 2008 5:33 PM To: List for Openmoko community discussion Subject: Re: GPS rework: Please test and report on software fix priorto attempting any hardware fix Agreed. I've been trying to gather that information for the past little while. It's proven rather elusive, and I didn't want more people to try the hardware fix until we really understand what the software fix can do, so I thought I'd better ask for the test ASAP, and then continue working on the info. Andy, can you provide links to two kernels: one before, and one after the fix? The test will consist something like cat /dev/ttySAC1 | grep GPGGA and then time it until it gets a fix. I'll be more specific. Perhaps I'll set up a wiki page for this. Michael Josh Thompson wrote: Could we get a link to some image files to use for this testing? I'm not quite sure when Andy's fix made it in the kernel. It would also help standardize the tests if we all use the same images. Josh On Mon August 4 2008 7:29:17 pm Michael Shiloh wrote: Before we conclude that the hardware fix is required, we'd really like to gather a lot of statistics from you about the behavior of the software fix. We have been able to test in only a limited number of locations, and a limited number of phones. We'd like to ask you to run some tests and report back the TTFF in each case: 1. Prior to Andy's software fix 1a. Without SD card 1b. With SD card 2. Using Andy's software fix 2a. Without SD card 2b. With SD card Preferably run this test in multiple locations. Results should be reported on a wiki page, which should include your location (so we can assess other influences e.g. satellite elevation and weather conditions) Thanks, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix priorto attempting any hardware fix
Hello, It seems I have an issue with my GPS, I did the software upgrade (last uboot, abd ASU 2008.8 kernel and rootfs) but still, it takes more than 5 minutes for my GPS to get a fix, without SIM card, without SD card, Without Wifi enable, in a open area What should I do ? do you have a reliable procedure that will concude I have a problem, if it is determine I have a problem, what is the next step ? Regards Philippe On Sun, Aug 10, 2008 at 8:21 PM, steve [EMAIL PROTECTED] wrote: A wiki wont do. A proper test proceedure and test report is called for. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Shiloh Sent: Monday, August 04, 2008 5:33 PM To: List for Openmoko community discussion Subject: Re: GPS rework: Please test and report on software fix priorto attempting any hardware fix Agreed. I've been trying to gather that information for the past little while. It's proven rather elusive, and I didn't want more people to try the hardware fix until we really understand what the software fix can do, so I thought I'd better ask for the test ASAP, and then continue working on the info. Andy, can you provide links to two kernels: one before, and one after the fix? The test will consist something like cat /dev/ttySAC1 | grep GPGGA and then time it until it gets a fix. I'll be more specific. Perhaps I'll set up a wiki page for this. Michael Josh Thompson wrote: Could we get a link to some image files to use for this testing? I'm not quite sure when Andy's fix made it in the kernel. It would also help standardize the tests if we all use the same images. Josh On Mon August 4 2008 7:29:17 pm Michael Shiloh wrote: Before we conclude that the hardware fix is required, we'd really like to gather a lot of statistics from you about the behavior of the software fix. We have been able to test in only a limited number of locations, and a limited number of phones. We'd like to ask you to run some tests and report back the TTFF in each case: 1. Prior to Andy's software fix 1a. Without SD card 1b. With SD card 2. Using Andy's software fix 2a. Without SD card 2b. With SD card Preferably run this test in multiple locations. Results should be reported on a wiki page, which should include your location (so we can assess other influences e.g. satellite elevation and weather conditions) Thanks, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
On Tuesday August 5, [EMAIL PROTECTED] wrote: For a bit more consistency of timing, less manual intervention, and enough readings to get an idea of the run to run variation in that location, can I suggest a script? It could do with a timeout when waiting for a fix since with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly forever in some locations! Thanks for the script. After wondering for a while why it didn't work at all for me, I added stty min 1 /dev/ttySAC1 because either frameworkd in FSO or openmoko-agpsui did an stty min 0 /dev/ttySAC1 and that caused grep to exit immediately. Anyway, I haven't let it run completely yet, but the first result is d i time 0 0 real 9m 52.15s Yes, nearly 10 minutes. This is indoors, but I have had problems getting a GPS fix everywhere, inside, outside, in a car, in the park. Once it fixes it tracks OK (though it doesn't recover from going into a shopping complex and coming out again). It seems a lot like the originally reported problem, but this is with a kernel that has the fix and the magic sysfs files: Linux om-gta02 2.6.24 #1 PREEMPT Tue Jul 29 01:19:38 UTC 2008 armv4tl unknown I have the wireless going, but GSM is possibly turned off as I killed frameworkd to make sure it wasn't touching the GPS. I know someone who I trust to solder the capacitor - should I try that (if I can get hold of him)? Another result just came in: d i time 0 0 real 9m 52.15s 0 1 real 8m 29.79s These numbers are actually pretty good. openmoko-agpsui was giving me 1000 or 2100 seconds! I decided to take out the SD card (and the SIM card) and try again. (just chat quietly among yourselves while we wait for the first result). d i time 0 0 real 5m 14.32s 0 1 real 2m 56.78s 1 0 real 5m 37.79s Well, that wasn't so bad. But still not what I hoped for. I'm wondering if I got a lemon :-( NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Al Johnson wrote: | | For a bit more consistency of timing, less manual intervention, and enough | readings to get an idea of the run to run variation in that location, can I | suggest a script? It could do with a timeout when waiting for a fix since | with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly | forever in some locations! | | I was just about to write a similar script when I saw yours hit my | inbox... other than a couple of assumptions, I like yours better than | what I had in mind These are really interesting, thanks. | d i min / avg / max | 0 0 35.20/ 55.33/144.30 === | 0 1 37.39/ 77.76/315.76 | 3 0 36.07/ 42.07/ 47.82 === | 3 1 97.46/173.09/359.69 These relative numbers are a bit counterintuitive... it might be worth trying it again from a very cold boot but with the script for DRIVESTRENGTH in 3 2 1 0 and seeing if the bias to a worse max moves accordingly. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiZSEYACgkQOjLpvpq7dMqZ0wCfUXoX3HMgYVcZOTehrASDkowr QicAnR5AVWf4MqqjdtMH7Kg8qbtLnvrl =nGv9 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
Andy Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Al Johnson wrote: | | For a bit more consistency of timing, less manual intervention, and enough | readings to get an idea of the run to run variation in that location, can I | suggest a script? It could do with a timeout when waiting for a fix since | with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly | forever in some locations! | | I was just about to write a similar script when I saw yours hit my | inbox... other than a couple of assumptions, I like yours better than | what I had in mind These are really interesting, thanks. | d i min / avg / max | 0 0 35.20/ 55.33/144.30 === | 0 1 37.39/ 77.76/315.76 | 3 0 36.07/ 42.07/ 47.82 === | 3 1 97.46/173.09/359.69 These relative numbers are a bit counterintuitive... it might be worth trying it again from a very cold boot but with the script for DRIVESTRENGTH in 3 2 1 0 and seeing if the bias to a worse max moves accordingly. - -Andy Hey Andy, I started a draft of a wiki page here http://wiki.openmoko.org/wiki/Freerunner_GPS_Software_Fix_TTFF_Measurement_Test to describe the test and to collect the results. Can you please add the line you suggest to the script? Thanks, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | I started a draft of a wiki page here | http://wiki.openmoko.org/wiki/Freerunner_GPS_Software_Fix_TTFF_Measurement_Test | to describe the test and to collect the results. Can you please add the | line you suggest to the script? I started editing that page but I don't know what we're trying to do with asking for mass data collection. I think it's OK to get a few results from this script and we get a clear idea, that and Stacy's work yesterday anyway put a limit on how bad the situation is with SD Card loaded: it's not that bad. People don't need to nuke their machine and rootfs two different ways, all they need is current kernel and they can turn the various changes on and off with the script. Plus, it is dangerous to go on just updating kernel partition by hand, people need to use kernel packages so their modules get updated too. The line in the script I mentioned is just something to try to see if there is a bias against the first test run, it changes an existing line there which is otherwise OK. I guess results from this script get skewed because of this sticky behaviour that the GPS chip can apparently remember things between power cycling. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiZT2UACgkQOjLpvpq7dMp+pwCeJl72T8+joEjVYaGkelFtxTFl nPcAniia59IJr/l5C5HIJYY/IQZ3ypSL =DtXQ -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
On Wednesday 06 August 2008, Andy Green wrote: | d i min / avg / max | 0 0 35.20/ 55.33/144.30 === | 0 1 37.39/ 77.76/315.76 | | 3 0 36.07/ 42.07/ 47.82 === | 3 1 97.46/173.09/359.69 These relative numbers are a bit counterintuitive... it might be worth trying it again from a very cold boot but with the script From experience writing the script I think they look within the normal range of variation for a FR sitting near a window, and that if you increased PASSES the stats for all of the IDLECLK=0 runs would look the same if the card wasn't being exercised. I got to see a lot of such apparently counterintuitive results before I forced access to the card after writing the sysfs entries! From the same location some runs have a best ttff of ~150s while others are consistent at around 35-40s. Some start with good ttff, go through a period of poor ttff then back to good again. This would be more visible if people posted the raw results rather than the statistics. I suspect from a couple of observations that a GSM register may make ttff longer, but I don't have any data to back that up - it may just have been unlucky. Any ideas on how GSM status could be factored in? I suppose I should post some results too. Note the 2 results where there seems to have been a GPRMC result sitting in a serial buffer or something. d i time 0 0 real 2m 20.77s 0 1 real 6m 5.84s 1 0 real 2m 7.67s 1 1 real 3m 6.97s 2 0 real 1m 19.33s 2 1 real 9m 59.40s 3 0 real 0m 49.44s 3 1 real 1h 15m 34s 0 0 real 2m 6.22s 0 1 real 6m 25.13s 1 0 real 0m 58.47s 1 1 real 4m 45.95s 2 0 real 2m 10.15s 2 1 real 5m 55.50s 3 0 real 1m 24.57s 3 1 real 54m 27.04s 0 0 real 2m 14.25s 0 1 real 5m 49.14s 1 0 real 0m 40.93s 1 1 real 4m 54.68s 2 0 real 0m 55.83s 2 1 real 5m 39.02s 3 0 real 0m 39.20s 3 1 real 7m 32.77s 0 0 real 0m 46.20s 0 1 real 3m 6.79s 1 0 real 0m 38.62s 1 1 real 1m 20.72s 2 0 real 0m 48.52s 2 1 real 4m 4.87s 3 0 real 1m 3.03s 3 1 real 5m 56.27s 0 0 real 0m 53.03s 0 1 real 2m 8.48s 1 0 real 2m 40.71s 1 1 real 1m 57.13s 2 0 real 2m 1.89s 2 1 real 2m 59.68s 3 0 real 0m 57.95s 3 1 real 4m 41.03s 0 0 real 0m 42.63s 0 1 real 2m 10.56s 1 0 real 0m 46.22s 1 1 real 0m 0.14s 2 0 real 0m 48.24s 2 1 real 5m 40.03s 3 0 real 0m 56.11s 3 1 real 9m 16.78s 0 0 real 0m 38.74s 0 1 real 1m 3.09s 1 0 real 0m 49.23s 1 1 real 0m 0.14s 2 0 real 0m 48.09s 2 1 real 2m 47.54s 3 0 real 0m 53.33s 3 1 real 9m 18.26s 0 0 real 0m 40.45s 0 1 real 2m 10.75s 1 0 real 0m 46.27s 1 1 real 3m 10.67s 2 0 real 0m 48.13s 2 1 real 3m 24.71s 3 0 real 0m 37.41s 3 1 real 10m 9.89s 0 0 real 0m 39.93s 0 1 real 1m 9.94s 1 0 real 0m 39.97s 1 1 real 2m 2.57s 2 0 real 0m 47.56s 2 1 real 3m 36.03s 3 0 real 0m 43.44s 3 1 real 6m 16.24s 0 0 real 2m 1.56s 0 1 real 3m 13.48s 1 0 real 0m 40.60s 1 1 real 2m 37.83s 2 0 real 0m 39.71s 2 1 real 2m 31.22s 3 0 real 0m 51.98s 3 1 real 6m 3.22s ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | On Wednesday 06 August 2008, Andy Green wrote: | | d i min / avg / max | | 0 0 35.20/ 55.33/144.30 === | | 0 1 37.39/ 77.76/315.76 | | | | 3 0 36.07/ 42.07/ 47.82 === | | 3 1 97.46/173.09/359.69 | | These relative numbers are a bit counterintuitive... it might be worth | trying it again from a very cold boot but with the script | | From experience writing the script I think they look within the normal range | of variation for a FR sitting near a window, and that if you increased PASSES | the stats for all of the IDLECLK=0 runs would look the same if the card | wasn't being exercised. I got to see a lot of such apparently | counterintuitive results before I forced access to the card after writing the | sysfs entries! From the same location some runs have a best ttff of ~150s I guess it means there are random accesses to SD Card in background. | I suspect from a couple of observations that a GSM register may make ttff | longer, but I don't have any data to back that up - it may just have been | unlucky. Any ideas on how GSM status could be factored in? Make a call and whistle is what I would do. But there is pretty much no latitude (ha) for meddling with what GSM side is going to do. | I suppose I should post some results too. Note the 2 results where there seems | to have been a GPRMC result sitting in a serial buffer or something. I guess it won't hurt to sleep 3 after turning it off before turning it back on. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiZeToACgkQOjLpvpq7dMrO4QCeLjWfOXDMVY+7ZgG0EEI8Ewv/ sw4An3067DpkKz4E1LEsGFDh4bz2Z19r =xr+V -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
On Wednesday 06 August 2008, Andy Green wrote: | sysfs entries! From the same location some runs have a best ttff of ~150s I guess it means there are random accesses to SD Card in background. Perhaps, but I think I saw similar variation from the same location with the SD card removed when the link was first discovered. It may be the GSM, the constellation, or a neighbour using some crappy device that spews interference too. I might try a few runs with the SD removed to get a baseline for variation not attributable to the SD. | I suspect from a couple of observations that a GSM register may make ttff | longer, but I don't have any data to back that up - it may just have been | unlucky. Any ideas on how GSM status could be factored in? Make a call and whistle is what I would do. But there is pretty much no latitude (ha) for meddling with what GSM side is going to do. I was thinking more of recording when the reregisters were taking place or something. I know we don't have control over it, but I would like to rule it in or out as a cause of interference. I wouldn't want you scratching your head over further ways to reduce interference from the SD if GSM or some other source was now the dominant factor. | I suppose I should post some results too. Note the 2 results where there seems | to have been a GPRMC result sitting in a serial buffer or something. I guess it won't hurt to sleep 3 after turning it off before turning it back on. It already sleeps 20 after switch off as an attempt to get a properly cold start, but I don't know if it's long enough for the ublox chip to lose its memory. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
Andy Green wrote: These are really interesting, thanks. | d i min / avg / max | 0 0 35.20/ 55.33/144.30 === | 0 1 37.39/ 77.76/315.76 | 3 0 36.07/ 42.07/ 47.82 === | 3 1 97.46/173.09/359.69 These relative numbers are a bit counterintuitive... it might be worth trying it again from a very cold boot but with the script for DRIVESTRENGTH in 3 2 1 0 and seeing if the bias to a worse max moves accordingly. So I broke the first rule of testing, and changed a bunch of things and then reran the test. First, instead of doing a power off/power on of the GPS, I used Andy's handy dandy UBX construction kit to issue a cold restart to the chip. If I understand the documentation correctly, this will wipe everything from the GPS's memory and do a hardware reset; that should take care of any concerns about residual fix information surviving a power cycle. Second, as Andy suggested, I reversed the order of DRIVESRENGTH values. And finally, I left WLAN enabled (mainly because I did a reboot of the FreeRunner and then ran the test). Here are the results: d i min / avg / max 0 0 36.41/ 51.53/ 84.83 0 1 40.41/ 59.13/128.33 1 0 36.98/ 45.45/ 51.03 1 1 40.94/ 63.74/111.77 2 0 31.43/ 45.08/ 52.31 2 1 32.57/ 57.50/ 76.06 3 0 32.10/ 43.75/ 57.98 3 1 40.34/ 61.71/ 96.67 BTW, the magic incantation to generate the cold restart is ubxcs b5 62 06 04 04 00 ff ff 00 00 coldstart.ubx Then to issue the command, cat coldstart.ubx /dev/ttySAC1 grep '$GPTXT,01,01,02,u-blox' -q -m 1 /dev/ttySAC1 The grep command looks for the powerup message from the GPS to make sure that there is no RMC sentence sitting in a buffer somewhere. -stacy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
On Tuesday 05 August 2008, Michael Shiloh wrote:
Agreed. I've been trying to gather that information for the past little
while. It's proven rather elusive, and I didn't want more people to try
the hardware fix until we really understand what the software fix can
do, so I thought I'd better ask for the test ASAP, and then continue
working on the info.
Andy, can you provide links to two kernels: one before, and one after
the fix?
IIRC the first kernel to have the sd_drive and sd_idleclk fixes in was from
20080723, but this seems to have been removed from the buildhost now. Or did
you mean the fix to slow down the SD clock while GPS is enabled that was
added Friday? In either case I think t can be configured to behave as it did
before the fix by echoing the right variables into /sys/wherever and
accessing the SD card.
The test will consist something like
cat /dev/ttySAC1 | grep GPGGA
and then time it until it gets a fix. I'll be more specific.
For a bit more consistency of timing, less manual intervention, and enough
readings to get an idea of the run to run variation in that location, can I
suggest a script? It could do with a timeout when waiting for a fix since
with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly
forever in some locations!
#!/bin/sh
PASSES=10
TTFF=
get_ttf() {
echo 1 /sys/bus/platform/devices/neo1973-pm-gps.0/pwron
TTFF=`(time grep GPRMC,[0-9\.]*,A, -m 1 /dev/ttySAC1) 21 |grep real`
echo 0 /sys/bus/platform/devices/neo1973-pm-gps.0/pwron
echo $DRIVESTRENGTH $IDLECLK $TTFF
sleep 20
}
echo d i time
until [ $PASSES -eq 0 ]
do
for DRIVESTRENGTH in 0 1 2 3
do
for IDLECLK in 0 1
do
#echo testing drive strength $DRIVESTRENGTH and clock idle $IDLECLK
echo $DRIVESTRENGTH /sys/module/glamo_mci/parameters/sd_drive
echo $IDLECLK /sys/module/glamo_mci/parameters/sd_idleclk
touch /media/card/gpstest
sync
get_ttf
done
done
PASSES=$(($PASSES-1))
done
Perhaps I'll set up a wiki page for this.
Michael
Josh Thompson wrote:
Could we get a link to some image files to use for this testing? I'm not
quite sure when Andy's fix made it in the kernel. It would also help
standardize the tests if we all use the same images.
Josh
On Mon August 4 2008 7:29:17 pm Michael Shiloh wrote:
Before we conclude that the hardware fix is required, we'd really like
to gather a lot of statistics from you about the behavior of the
software fix. We have been able to test in only a limited number of
locations, and a limited number of phones.
We'd like to ask you to run some tests and report back the TTFF in each
case:
1. Prior to Andy's software fix
1a. Without SD card
1b. With SD card
2. Using Andy's software fix
2a. Without SD card
2b. With SD card
Preferably run this test in multiple locations.
Results should be reported on a wiki page, which should include your
location (so we can assess other influences e.g. satellite elevation and
weather conditions)
Thanks,
Michael
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
Hi all, Just to let you know, I tried the above script and am not quite sure the gpsr is completely reset ( e.g. a real cold start occurs ) . However, since I DID apply the HW cap fix that might also be a reason for the results... In short, no matter which settings are used I get a TTFF of 38-42seconds, repeatably, with only a few seconds more when constant SD-Card activity is provoked. It was on a rooftop, clear sunny sky, about 1/5 of the sky/horizon covered by an appartment, but results are consistent with my observations during geocaching in any terrain, be it cities or woods. Let me know if I can be of further assistance getting data, ( and of course this report of great gpsr performance should not lead anyone to try out the HW mod until final approval by OM ;-) ! ) Stefan ### Kernel version Linux om-gta02 2.6.24 #1 PREEMPT Sat Aug 2 00:43:10 CEST 2008 armv4tl unknown ### ROOT ( opkg upgraded today ) 200807160132 Tag Name: VERSION: 27cd6d55ab393f51eaf4811418a4346669f53c2a Branch: org.openmoko.dev Build Host: buildhost.openmoko.org Time Stamp: Wed, 16 Jul 2008 01:34:56 +0200 ### Bootloader # u-boot /dev/mtdblock0: Neo1973 Bootloader U-Boot 1.3.2-moko12 # u-boot /dev/mtdblock1: Neo1973 Bootloader U-Boot 1.3.2+gitr18+64eb10cab8055084ae25ea4e73b66dd03cc1a0cb ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
When you are collecting data you might also keep in mind conditions vary a lot according to the current satellite constellation. You should include the count of satellites in view and the pdop number with your results data. You can do some planning to make sure you don't run one test when conditions are good and then another tomorrow when conditions are bad by using mission planning software. See my comments here: http://wildsong.biz/index.php?title=GPS_mission_planning_software including a link to a Windows program that is available from Trimble for free. (If anyone knows of an open source planning program do let me know!) Brian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
