Re: Recalibration, band conversion and bug #1024 rework
On Wed 14 February 2018 14:40:01 Mychaela Falconia wrote: > Hello OM community, > > I am pleased to announce that my company Falconia Partners LLC is now > offering GSM RF tract recalibration services ... Excellent news. Sounds like you're doing a great job there. Many thanks for that cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Recalibration, band conversion and bug #1024 rework
Hello OM community, I am pleased to announce that my company Falconia Partners LLC is now offering GSM RF tract recalibration services for Openmoko's Neo 1973 and Neo FreeRunner devices. Like all other commercial GSM phones and modems, these smartphones had their GSM RF parameters individually calibrated on the factory production line. This factory calibration normally persists for the lifetime of the device, but because the calibration values are stored in the Calypso modem's flash file system, it is possible that some Neo owners may have lost theirs as a result of careless playing with modem flashing tools. The latter scenario is quite likely to have happened in the bad old days before FreeCalypso when the modem was treated as some kind of "thou shalt not enter" forbidden zone, and the modem flashing tools and documentation were available only in a hush-hush, whisper-whisper manner. GSM RF calibration also needs to be redone if the RF hardware has been physically modified in any way, e.g., to convert a 900 MHz device to 850 MHz or vice-versa. Because my company produces new Calypso GSM modems that are very similar to Openmoko's, we have the necessary facilities to perform our own RF calibration that is no worse than what OM's factory did. The RF test instrument that is used to perform the calibration is a Rohde CMU200, and this instrument itself needs to be kept in good calibration standing - the chain of traceability goes back to national standards labs like NIST. Our CMU200 instrument has just been calibrated by Rohde in Maryland; here is the official calibration certificate: https://www.freecalypso.org/members/falcon/calibration/CD_5000-309076293.pdf In addition to the measuring instrument, the process of calibrating the RF tract on a Calypso GSM device involves special software that talks both to the firmware running on the Calypso (which naturally needs to be TI-based) and to the CMU200 or other external RF test equipment. The original software that was used by OM's factory appears to have been lost, hence an entirely new replacement had to be developed from scratch here at Falconia Partners LLC, based on the available bits of documentation from TI and meticulous reverse engineering. Our new calibration software is freely published, so you can see exactly what we do when we calibrate a Calypso GSM device: https://bitbucket.org/falconian/fc-rfcal-tools If anyone has a GTA02 or GTA01 device that needs to be recalibrated or could benefit from such, you can send it to Falconia Partners LLC to be serviced. As long as the demand is low, there will be no charge for the recalibration service other than return shipping. If you are going to sending your device in for service, please take the battery out, i.e., send the device WITHOUT the battery. Postal services have become very uptight about lithium batteries recently, hence the return shipping will cost a lot more if I have to deal with the extra bureaucratic hurdles of shipping the device back to you with that Li-ion battery in it. The calibration service is completely non-invasive, i.e., your device won't need to be disassembled beyond taking the back cover off. Your Neo will have 3 cables plugged into it (USB for talking to U-Boot, another USB-serial cable in the headset jack for talking to the Calypso, and an RF test cable going to the CMU200 inserted into the RF test port under the back cover), the application processor will be booted into NOR U-Boot, the latter will be used to execute neo gsm on and neo gsm off commands via USB, and the headset jack serial port will be used to operate on the Calypso modem. Whatever software you are running on the phone's application processor will be left completely untouched. If there is interest, my company may also be able to offer a band conversion service, i.e., converting a 900 MHz FreeRunner to 850 MHz or vice-versa. To make such conversion, one SAW filter part in the GSM section of the motherboard needs to be changed (populate Epcos B7820 for 900 MHz or B7845 for 850 MHz), followed by recalibration. However, unlike pure recalibration, band conversion would require a bit of invasive surgery on the hardware, and this hw surgery would need to be performed at a professional board assembly and rework shop. If there is any serious interest, I can have a discussion with Technotronix (the shop where our new FreeCalypso modem boards are assembled) and see if they would be able to perform rework on Openmoko devices, and how much they would charge for the service. I won't be adding any margin of my own on top of whatever Technotronix folks will charge, but I would need to act as a middlewoman for logistics because devices would need to be recalibrated after the SAW filter change, and the calibration station with the CMU200 (a big, heavy and expensive instrument) resides in my own lab, not at Technotronix. Finally, if anyone has a FreeRunner that hasn't had the rework for
Neo FR disassembly for bug #1024 rework
Hello OM community, I know that a good number of Neo FreeRunner units have been subjected to the hardware rework to fix the infamous bug #1024, and it is my understanding that one or more shops used to perform this rework service professionally once upon a time. I am now looking into the possibility of having my company Falconia Partners LLC offer this hw rework service, as I have heard reports from FreeRunner owners who say that their units never got the rework and do suffer from the bug, and I would also like to be able to offer a band conversion service, i.e., converting any given FreeRunner between 850 MHz and 900 MHz bands in either direction. The band conversion would involve changing one SAW filter component at reference designator U402 (populate Epcos B7820 for 900 MHz or B7845 for 850 MHz, I have the parts readily available) followed by recalibration - and my little company has just the right RF test equipment setup (and newly developed calibration software that fully replicates the functionality of the apparently-lost Windows version used by OM/FIC) to do the latter. The extent of required disassembly is exactly the same for bug #1024 rework and for the SAW filter change - in both cases the metal shieldcan cover over the GSM section of the motherboard needs to be removed, and both reworks can be done in the same surgery. I do wonder, however, if any of the people who used to perform bug #1024 rework in the past on a professional basis (i.e., on customer devices, not their own personal ones) might be willing to share some tips as to what would be the absolutely least invasive way to open that shieldcan and then put it all back together after the surgery. One complication that exists on GTA02 devices but not on GTA01 (nor on my newly made FCDEV3B modems) is that the WLAN daughterboard sits directly on top of the shieldcan cover over the GSM section, and the two are bonded together with some material that seems to be some form of conductive glue. It is not a strong glue, i.e., the WLAN module can be easily pulled off by hand, but pulling it off like this leaves a mess underneath, and thus I assume that my naive way of doing it is probably not the right way. Hence I wonder if any of the people who used to do the rework for bug #1024 professionally might be willing to share the secret of how to do it right: 1) Did you remove the WLAN daughterboard first and then lift the shieldcan cover, or did you somehow remove these two pieces together so they remain attached to each other with that bonding material? 2) If you removed the two pieces separately, how did you restore the bonding between them upon reassembly? 3) If it is possible to remove the shieldcan cover along with the WLAN module on top of it as a single piece, how does one do it? TIA for any tips, Mychaela ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
gta02 bass and #1024 bug rework
Hi list I have a GTA02A7, is there someone in Europe who still offer the bass (not buzz) and #1024 bug rework? Thanks. Regards Joif ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ANN] Buzz/#1024/Bass-Rework = Headset Audio Quality Enhancement available in EU
because we have been asked: we continue to offer these rework services and the GTA02A7++ variant. Regards, Nikolaus Am 23.03.2010 um 10:42 schrieb Dr. H. Nikolaus Schaller: just let me follow-up that we can ship A7++ devices by end of the week. They are originals from factory and we have applied #1024 and Bass-Rework (Buzz-Rework is not required for A7 units). Please look at http://www.handheld-linux.com/wiki.php?page=Neo%20Freerunner BR, Nikolaus Am 18.03.2010 um 14:39 schrieb Dr. H. Nikolaus Schaller: Am 18.03.2010 um 13:41 schrieb Xavier Cremaschi: Is it possible to do bass-fix and 1024-fix on a device which had already been to Munchen to be buzz-fixed, or does it involve too many soldering operation to be reliable ? yes, no problem. All three reworks are done in very different areas of the device (Buzz is done at the Microphone; #1024 within the tin-can under the WLAN module and the Bass-Rework under the tin-can under the Bluetooth module). And therefore they can be done independently - or all together (which saves a lot of handling and shipment cost). And, they use professional equipment that does the least harm to the board that is possible. BR, Nikolaus Thanks for providing this service btw. Regards, Xavier. ___ 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: Detecting 1024 on qtmoko
Dne So 1. května 2010 15:38:12 Peter Mogensen napsal(a): Also... do QtMoko really log to files on flash or have I missed something. I would prefer logging to a ramfs like on SHR. Now it logs to flash. I have been experimenting with this a little. It's very wanted for next releases... Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Detecting 1024 on qtmoko
Also... do QtMoko really log to files on flash or have I missed something. I would prefer logging to a ramfs like on SHR. Now it logs to flash. I have been experimenting with this a little. It's very wanted for next releases... I use the following script: % cat /etc/init.d/syslog-busybox #!/bin/sh ### BEGIN INIT INFO # Provides: sysklogd # Required-Start: $remote_fs $time # Required-Stop:$remote_fs $time # Should-Start: $network # Should-Stop: $network # Default-Start:2 3 4 5 # Default-Stop: 0 1 6 # Short-Description:System logger ### END INIT INFO case $1 in start ) echo -n Starting Busybox syslog: if busybox syslogd -C16; then echo -n syslogd; else echo -n !syslogd!; fi if busybox klogd; then echo -n klogd; else echo -n !kogd!; fi echo . ;; esac % It should be made into a small Debian package, but I haven't spent the time yet to learn how to make such a thing. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Detecting 1024 on qtmoko
Peter Mogensen wrote: So do anyone have pointers to fool-proof 1024 bug detection on QtMoko Ok... upgrade to V22 and the problem with no network seemed to be solved by a cold start. Now QtMoko runs and the phone works with deep_sleep enabled, though it is not 1024-fixed. This is probably too good to be true, so how do I verify that there's no 1024 problem on QtMoko? (assuming I've warmed the phone enought for it to appear.) Also... do QtMoko really log to files on flash or have I missed something. I would prefer logging to a ramfs like on SHR. /Peter ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Bug 1024
Alishams Hassam alish...@interchange.ubc.ca writes: and disable the wifi. If the battery is still shit, leave wifi off after a restart and see if battery life improves. How about giving exact numbers by measuring the consumption using om battery consumption or via /sys directly? (I think you need current_now file). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Bug 1024
The correct value to fix #1024 in qtmoko in */opt/qtmoko /etc/default/Trolltech/Modem.conf* is *yes* instead of always (always is the value to use with SHR) -- Gand' On Sat, Apr 17, 2010 at 1:31 PM, Alfa21 freerun...@my.is.it wrote: another cause maybe: [quoting from wiki about debian] echo 500 /sys/module/glamo_mci/parameters/sd_max_clk echo 3 /sys/module/glamo_mci/parameters/sd_drive If that resolves the problem and installation completes, you are that much wiser. However, SD card performance is reduced even from the default, power consumption increases and SD card power could interfere with GPS functionality. [/quote] ...and qtmoko uses sd_max_clk in /etc/init.d/qpe.sh for compatibility reasons -- ALFA21 IS PROVIDED AS IS AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED. ___ 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: [QtMoko] Bug 1024
On Wed, 28 Apr 2010 10:31:30 +0200 Gand' gand...@viroenforce.com (G) wrote: The correct value to fix #1024 in qtmoko in */opt/qtmoko /etc/default/Trolltech/Modem.conf* is *yes* instead of always (always is the value to use with SHR) i have already corrected the 1024 page [1] on openmoko wiki if the confusion comes from there. this was the info i got from the ML. cheers Petr [1] http://wiki.openmoko.org/wiki/1024 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Bug 1024
On Wednesday 28 April 2010 10:31:30 Gand' wrote: The correct value to fix #1024 in qtmoko in */opt/qtmoko /etc/default/Trolltech/Modem.conf* is *yes* instead of always (always is the value to use with SHR) It's the same if you have always or yes. The code checks for never and activates deep sleep otherwise. http://github.com/radekp/qtmoko/blob/master/devices/neo/src/plugins/phonevendors/neo/vendor_neo.cpp if (deepsleep == never) chat(AT%SLEEP=2); else chat(AT%SLEEP=4); Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Bug 1024
really ? because always doesn't seem to work, as my battery life doesn't exceed a day with QTmoko, whereas it lasts more or less 3 days with SHR ... if it's not the #1024, what else ? -- Gand' On Wed, Apr 28, 2010 at 11:46 AM, Radek Polak pson...@seznam.cz wrote: On Wednesday 28 April 2010 10:31:30 Gand' wrote: The correct value to fix #1024 in qtmoko in */opt/qtmoko /etc/default/Trolltech/Modem.conf* is *yes* instead of always (always is the value to use with SHR) It's the same if you have always or yes. The code checks for never and activates deep sleep otherwise. http://github.com/radekp/qtmoko/blob/master/devices/neo/src/plugins/phonevendors/neo/vendor_neo.cpp if (deepsleep == never) chat(AT%SLEEP=2); else chat(AT%SLEEP=4); Regards Radek ___ 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: [QtMoko] Bug 1024
On Wed, 2010-04-28 at 23:11 +0200, Gand' wrote: really ? because always doesn't seem to work, as my battery life doesn't exceed a day with QTmoko, whereas it lasts more or less 3 days with SHR ... if it's not the #1024, what else ? -- Gand' Have you been using wifi? I know for sure on older versions of qtmoko if I enable wifi after suspend-resume it is disconnected but still shows as online in the GUI. I noticed my battery life would heavily suffer. Two thing you could try assuming this is still a problem. After using wifi and doing a suspend-resume, make sure you go into the internet menu and disable the wifi. If the battery is still shit, leave wifi off after a restart and see if battery life improves. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Detecting 1024 on qtmoko (and others)
Hi, I'm about to wake up from having spend the last year being 100% dependent on a always working phone, so the FR have been on the shelf. Now, I'm trying to figure out if I should have the phone #1024 fixed. Initial tests on SHR using the deep-sleep-check.py script from the Wiki and trying the AT-command sequence from handheld-linux.com seems to show no signs of the bug. However, when I tried with QtMoko and changed the deep sleep modem conf Active=never to Active=always, the PIN dialog never came up and QtMoko just showed a No network message. So do anyone have pointers to fool-proof 1024 bug detection on QtMoko and SHR? It seems what I've done until now points in 2 different directions. /Peter ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Detecting 1024 on qtmoko (and others)
On Friday 23 April 2010, Peter Mogensen wrote: Hi, I'm about to wake up from having spend the last year being 100% dependent on a always working phone, so the FR have been on the shelf. Now, I'm trying to figure out if I should have the phone #1024 fixed. Initial tests on SHR using the deep-sleep-check.py script from the Wiki and trying the AT-command sequence from handheld-linux.com seems to show no signs of the bug. However, when I tried with QtMoko and changed the deep sleep modem conf Active=never to Active=always, the PIN dialog never came up and QtMoko just showed a No network message. So do anyone have pointers to fool-proof 1024 bug detection on QtMoko and SHR? It seems what I've done until now points in 2 different directions. The QtMoko behaviour seems more like a bug than a manifestation of #1024. Since you don't get as far as entering the PIN it won't try to register. deep-sleep-check.py will show if you suffer from the bug at the time tested, but it is temperature dependent so test it when the phone is warm. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Bug 1024
another cause maybe: [quoting from wiki about debian] echo 500 /sys/module/glamo_mci/parameters/sd_max_clk echo 3 /sys/module/glamo_mci/parameters/sd_drive If that resolves the problem and installation completes, you are that much wiser. However, SD card performance is reduced even from the default, power consumption increases and SD card power could interfere with GPS functionality. [/quote] ...and qtmoko uses sd_max_clk in /etc/init.d/qpe.sh for compatibility reasons -- ALFA21 IS PROVIDED AS IS AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: [QtMoko] Bug 1024
Aslo see: http://qtmoko.org/wiki/FAQ#How_about_power_save_of_Calypso.2C_the_GSM_modem_-_bug_.231024 Niels. Date: Tue, 13 Apr 2010 23:19:26 +0200 From: yann.sla...@free.fr To: community@lists.openmoko.org Subject: Re: [QtMoko] Bug 1024 As said before, by modifying parameter 'Active' from' never' to 'always' and then reboot the phone Yann Yann SLADEKyann.sla...@free.fr writes: With QtMoko, I cannot go up to 20h, after modifying /opt/qtmoko/etc/default/Trolltech/Modem.conf _ Internet Explorer 8 : nu veiliger dan ooit dankzij nieuwe update http://www.microsoft.com/belux/nl/windows/internet-explorer/___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Bug 1024
Hi Niels, Already did it (1024 bug fix and parameter modified) Regards, Yann - Mail Original - De: Niels Heyvaert nielsheyva...@hotmail.com À: community@lists.openmoko.org Envoyé: Mercredi 14 Avril 2010 10:11:00 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: RE: [QtMoko] Bug 1024 Aslo see: http://qtmoko.org/wiki/FAQ#How_about_power_save_of_Calypso.2C_the_GSM_modem_-_bug_.231024 Niels. Date: Tue, 13 Apr 2010 23:19:26 +0200 From: yann.sla...@free.fr To: community@lists.openmoko.org Subject: Re: [QtMoko] Bug 1024 As said before, by modifying parameter 'Active' from' never' to 'always' and then reboot the phone Yann Yann SLADEKyann.sla...@free.fr writes: With QtMoko, I cannot go up to 20h, after modifying /opt/qtmoko/etc/default/Trolltech/Modem.conf U surft nog met Internet Explorer 6 of 7? Nu gratis upgraden ! ___ 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
[QtMoko] Bug 1024
Hi list, for the past few weeks, I tried both QtMoko and SHR with my FR (#1024 fixed by myself) With SHR, modifying /etc/frameworkd.conf did the trick and I can use my FR for approx. 65-70h in a normal way (few calls, text, wifi just for fun,etc..) With QtMoko, I cannot go up to 20h, after modifying /opt/qtmoko/etc/default/Trolltech/Modem.conf Anyone has the same problem ? Something else has to be done ? Thanks Yann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Bug 1024
(just a question: 70h suspension included? if yes how many hours of suspension?) d On Tue, Apr 13, 2010 at 9:18 PM, Yann SLADEK yann.sla...@free.fr wrote: Hi list, for the past few weeks, I tried both QtMoko and SHR with my FR (#1024 fixed by myself) With SHR, modifying /etc/frameworkd.conf did the trick and I can use my FR for approx. 65-70h in a normal way (few calls, text, wifi just for fun,etc..) With QtMoko, I cannot go up to 20h, after modifying /opt/qtmoko/etc/default/Trolltech/Modem.conf Anyone has the same problem ? Something else has to be done ? Thanks Yann ___ 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: [QtMoko] Bug 1024
On Tue, Apr 13, 2010 at 10:18 PM, Yann SLADEK yann.sla...@free.fr wrote: Hi list, for the past few weeks, I tried both QtMoko and SHR with my FR (#1024 fixed by myself) With SHR, modifying /etc/frameworkd.conf did the trick and I can use my FR for approx. 65-70h in a normal way (few calls, text, wifi just for fun,etc..) With QtMoko, I cannot go up to 20h, after modifying /opt/qtmoko/etc/default/Trolltech/Modem.conf Anyone has the same problem ? Something else has to be done ? Same here, Debian gives me days, qtmoko ~1 day 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: [QtMoko] Bug 1024
Yann SLADEK yann.sla...@free.fr writes: With QtMoko, I cannot go up to 20h, after modifying /opt/qtmoko/etc/default/Trolltech/Modem.conf I do not use qtmoko but how did you modify Modem.conf? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Bug 1024
On 13 April 2010 22:18, Yann SLADEK yann.sla...@free.fr wrote: Hi list, for the past few weeks, I tried both QtMoko and SHR with my FR (#1024 fixed by myself) With SHR, modifying /etc/frameworkd.conf did the trick and I can use my FR for approx. 65-70h in a normal way (few calls, text, wifi just for fun,etc..) With QtMoko, I cannot go up to 20h, after modifying /opt/qtmoko/etc/default/Trolltech/Modem.conf Anyone has the same problem ? Something else has to be done ? I have #1024 fixed and I changed Active=never to Active=always in /opt/qtmoko/etc/default/Trolltech/Modem.conf The battery life is about 3 days. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Bug 1024
Hi, I can't tell, count I use my FR for 30min a day for calls, maybe 30min-1h a day for missed calls and voicemail checking + shr playing :)) Same for QtMoko Yann (just a question: 70h suspension included? if yes how many hours of suspension?) d On Tue, Apr 13, 2010 at 9:18 PM, Yann SLADEK yann.sla...@free.fr mailto:yann.sla...@free.fr wrote: Hi list, for the past few weeks, I tried both QtMoko and SHR with my FR (#1024 fixed by myself) With SHR, modifying /etc/frameworkd.conf did the trick and I can use my FR for approx. 65-70h in a normal way (few calls, text, wifi just for fun,etc..) With QtMoko, I cannot go up to 20h, after modifying /opt/qtmoko/etc/default/Trolltech/Modem.conf Anyone has the same problem ? Something else has to be done ? Thanks Yann ___ Openmoko community mailing list community@lists.openmoko.org mailto: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: [QtMoko] Bug 1024
As said before, by modifying parameter 'Active' from' never' to 'always' and then reboot the phone Yann Yann SLADEKyann.sla...@free.fr writes: With QtMoko, I cannot go up to 20h, after modifying /opt/qtmoko/etc/default/Trolltech/Modem.conf I do not use qtmoko but how did you modify Modem.conf? ___ 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: Buzz-Fix and #1024 @ FOSDEM
Since we have been asked: this is not the official rework done by Handheld Linux (that is a paid rework company in Munich using stereo microscopes). I am just forwarding the news. Just go there, look and ask. At FOSDEM this is a really free and open hardware rework. Tuxbrain is also there, openmoko.fr is there and many others. So you can also see the Qi Nanonote and the Sharp Netwalker. Nikolaus Am 06.02.2010 um 15:38 schrieb Dr. H. Nikolaus Schaller: there is now a Buzz-Fix and #1024 fix opportunity at FOSDEM. Please go to the End of the hallway with the Stands. Opposite of the Room 1301 (Sallew Leon Cornil) you will find a booth where Openmokos and Nanonotes are shown. And a nice guy is sitting there with Soldering Iron waiting for your Openmoko. Nikolaus Mobile Office Solutions by Golden Delicious Computers GmbHCo. KG Buchenstr. 3 D-82041 Oberhaching +49-89-54290367 http://www.handheld-linux.com AG München, HRA 89571 VAT DE253626266 Komplementär: Golden Delicious Computers Verwaltungs GmbH Oberhaching, AG München, HRB 16602 Geschäftsführer: Dr. Nikolaus Schaller Digital Tools for Independent People ___ 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: [shr-u] kind of #1024?
Am Freitag 04 Dezember 2009 schrieb Matthias Eller: When the phone is suspended and a call is coming in it resumes and looses the gsm connection for a second (icon in the upper left changes) and then gets the gsm connection back (icon changes back to some bars). The caller gets some kind of temporarily not available at this time. I did an update last night. Now the phone resumes from suspend, show the no connection icon but keeps on ringing. The Caller hears that the phone is ringing. No connection-breaks now. ti_calypso_deep_sleep is still never. signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[shr-u] kind of #1024?
hello, I'm using the shr-full-eglibc-ipk--20091124-om-gta02.rootfs.jffs2 right now. The phone show a bug, which did not occur in former times. When the phone is suspended and a call is coming in it resumes and looses the gsm connection for a second (icon in the upper left changes) and then gets the gsm connection back (icon changes back to some bars). The caller gets some kind of temporarily not available at this time. If a call is coming in while the phone is not in suspend everything is fine. ti_calypso_deep_sleep is set to never. I've never seen this bug befor on my phone. So is this some kind of #1024, so it coul be fixed with a larger capacitor? signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] kind of #1024?
I've never seen this bug befor on my phone. So is this some kind of #1024, so it coul be fixed with a larger capacitor? sounds like the issue i was experiencing for weeks now with more recent fso-usaged, although with zhone. not sure if it is related to zhone or fso. my workaround was to use apmd and put a script into the resume scripts folder that calls the fso method to resume gsm. but then again, here did the fr lose connection completely when resumed ... anyway. i still suspect it to be related to #1024 somehow. need to get that fixed once i got hold of another cellphone for that time. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] kind of #1024?
don't know... check this: http://wiki.openmoko.org/wiki/1024#Bug_detection i also want to check if my fr suffers this bug but wiki says: Bug detection by fso: Just use frameworkd with ti_calypso_sleep_mode = 'adaptive' and inspect the logs. Frameworkd will tell you, when a real recamping exists. yes but, which logs??? Maybe two brains (or more) are better than one (tired... i'm going to sleep). Hope we'll find some info to complete the wiki d Matthias Eller ha scritto: hello, I'm using the shr-full-eglibc-ipk--20091124-om-gta02.rootfs.jffs2 right now. The phone show a bug, which did not occur in former times. When the phone is suspended and a call is coming in it resumes and looses the gsm connection for a second (icon in the upper left changes) and then gets the gsm connection back (icon changes back to some bars). The caller gets some kind of temporarily not available at this time. If a call is coming in while the phone is not in suspend everything is fine. ti_calypso_deep_sleep is set to never. I've never seen this bug befor on my phone. So is this some kind of #1024, so it coul be fixed with a larger capacitor? ___ 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: [shr-u] kind of #1024?
yes but, which logs??? Maybe two brains (or more) are better than one (tired... i'm going to sleep). configure a log file in /etc/frameworkd.conf and check that. there're some example-like lines at the top of that file. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] kind of #1024?
OK thanks i'll try tomorrow ;-) On 12/4/09, arne anka openm...@ginguppin.de wrote: yes but, which logs??? Maybe two brains (or more) are better than one (tired... i'm going to sleep). configure a log file in /etc/frameworkd.conf and check that. there're some example-like lines at the top of that file. ___ 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
Recamping (#1024) fix
A few days ago, I received my FR back from Golden Delicious, who had performed the recamping (#1024) fix. He was very prompt - it took Hermes longer to get my FR to him than it did for him to fix it and send it back. I'm not connected in any way to Golden Delicious, apart from as a satisfied customer. Regards Jeff signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Recamping (#1024) fix
On Monday 23 Nov 2009 20:29:23 Jeffrey Ratcliffe wrote: A few days ago, I received my FR back from Golden Delicious, who had performed the recamping (#1024) fix. He was very prompt - it took Hermes longer to get my FR to him than it did for him to fix it and send it back. I'm not connected in any way to Golden Delicious, apart from as a satisfied customer. Regards Jeff I'll second that one. solar.george signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Recamping (#1024) fix
Am Montag 23 November 2009 schrieb George Brooke: On Monday 23 Nov 2009 20:29:23 Jeffrey Ratcliffe wrote: A few days ago, I received my FR back from Golden Delicious, who had performed the recamping (#1024) fix. He was very prompt - it took Hermes longer to get my FR to him than it did for him to fix it and send it back. I'm not connected in any way to Golden Delicious, apart from as a satisfied customer. Regards Jeff I'll second that one. An a third one :-) My advantage was, that Golden Delicious is almost in the neighbourhood and even better: we had two informal user meetings in Munich within a week, so instead of relying on Hermes I could hand over the freerunner directly and receive it back the same way. The service is really first class (As Jeffrey wrote: This is my opinion as happy customer!) -- Lars Lubarsky's Law of Cybernetic Entomology: There's always one more bug. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Symptoms of failed #1024 fix
On Sun, Nov 01, 2009 at 08:54:50PM +0100, Jens Seidel wrote: On Sun, Nov 01, 2009 at 05:57:28PM +0100, Christophe M wrote: /var/log/frameworkd.log: 2009.11.01 17:25:06.733 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds I just want to confirm that these symptoms mean that the soldering was not properly done so that no capacitor is used instead of the 10uF or 22uF one. I will ask the engineer who performed this task for me to do it again to get a proper phone. I get no prompt for the SIM pin which worked in the past and also mickeyterm exits with a DBus exception before I can enter a single command. As the engineer told me he isn't sure about the soldering I assumed it wasn't done well ... If it works again after the resoldering I will drop a mail. Resoldering was performed and now all modem related problems vanished. Also my device is now #1024 bug free :-)) Don't know about the increase of battery time as I nearly always have it connected to USB but maybe it's time to unplug it ... Jens ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Symptoms of failed #1024 fix
Hi, you performed a #1024 bug and can no longer access to modem? You get in /var/log/frameworkd.log: 2009.11.01 17:25:06.733 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.11.01 17:25:06.743 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.11.01 17:26:08.523 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.11.01 17:26:08.533 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.11.01 17:26:21.733 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.11.01 17:26:21.743 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' This happened to me too on every boot of SHR. I just want to confirm that these symptoms mean that the soldering was not properly done so that no capacitor is used instead of the 10uF or 22uF one. I will ask the engineer who performed this task for me to do it again to get a proper phone. I also want to mention that I did not observed other problems. The device boots fine, the touchscreen and USB works, ... GPS failed for me but maybe I did not properly plugged the antenna. Some programs such as Cellhunter stop now with: An exit code of 1 was returned from /usr/bin/cellhunter.py So even if the capacitor cannot properly solded again I have a fine device :-) Jens ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Symptoms of failed #1024 fix
Hi, you performed a #1024 bug and can no longer access to modem? You get in /var/log/frameworkd.log: 2009.11.01 17:25:06.733 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.11.01 17:25:06.743 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.11.01 17:26:08.523 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.11.01 17:26:08.533 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.11.01 17:26:21.733 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.11.01 17:26:21.743 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' This happened to me too on every boot of SHR. I just want to confirm that these symptoms mean that the soldering was not properly done so that no capacitor is used instead of the 10uF or 22uF one. I will ask the engineer who performed this task for me to do it again to get a proper phone. I also want to mention that I did not observed other problems. The device boots fine, the touchscreen and USB works, ... GPS failed for me but maybe I did not properly plugged the antenna. Some programs such as Cellhunter stop now with: An exit code of 1 was returned from /usr/bin/cellhunter.py So even if the capacitor cannot properly solded again I have a fine device :-) Jens Hi ! I have the same error while I'm on roaming but I haven't done the 1024 fix so I'm not sure it's related ... -- -- Openmoko phone gui : http://www.qalee.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Symptoms of failed #1024 fix
On Sun, Nov 01, 2009 at 05:57:28PM +0100, Christophe M wrote: /var/log/frameworkd.log: 2009.11.01 17:25:06.733 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds I just want to confirm that these symptoms mean that the soldering was not properly done so that no capacitor is used instead of the 10uF or 22uF one. I will ask the engineer who performed this task for me to do it again to get a proper phone. I have the same error while I'm on roaming but I haven't done the 1024 fix so I'm not sure it's related ... There was at least a further Google hit on the messages above with relation to a #1024 bugfix and I just tried to confirm it. I get no prompt for the SIM pin which worked in the past and also mickeyterm exits with a DBus exception before I can enter a single command. As the engineer told me he isn't sure about the soldering I assumed it wasn't done well ... dmesg outputs: [ 1068.535000] modem wakeup interrupt [ 1081.725000] modem wakeup interrupt [ 1094.915000] modem wakeup interrupt [ 1108.11] modem wakeup interrupt [ 1121.34] modem wakeup interrupt [ 1134.54] modem wakeup interrupt [ 1147.74] modem wakeup interrupt [ 1160.935000] modem wakeup interrupt [ 1174.125000] modem wakeup interrupt [ 1187.31] modem wakeup interrupt [ 1200.51] modem wakeup interrupt On the other hand I did most tests (except the initial ones) with a disassembled device (without GSM and GPS antenna, no WLAN module and battery) ... If it works again after the resoldering I will drop a mail. Jens ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
Hi Michael, i'm also interested in doing teh rework on my own, but on this page http://wiki.openmoko.org/wiki/1024 and related links there are only few images... so can you please post yours when your work is done? thanks d (if you want/can you can contact me directly) On Fri, Oct 23, 2009 at 11:29 AM, Michael Smith michael.sm...@netapps.com.au wrote: On Fri, 23 Oct 2009 21:05:50 +1100 Chris Samuel ch...@csamuel.org wrote: Or Australia ? Hi. I'm in Melbourne too. Needing to buzz fix an A6 I asked a few electronics engineers. I was looking for somebody who would do delicate soldering work for an hourly rate. The consensus from people I spoke to was that while there are a few small businesses who do electronic work, few would be interested in small jobs. A co-worker of mine offered to do the buzz fix for me. This person tends to over rate his ability. I should have remembered this when I agreed for him to do the work. I plan to tool up and redo the soldering on that phone in the next couple of weeks. The problem with little jobs like this is liability. If he stuffs up, who takes responsibility? On small jobs it is impossible to get insurance. So I am going to do a buzz fix soon. The #1024 fix seems more complicated because you have to disassemble parts of the phone which may be hard to put back together. I might try this procedure on the phone which I am going to do the buzz fix on. I can more afford to stuff that one up. I will post the results here: http://glitch.tl/working_with_shr.html Regards, -- Michael Smith Network Applications www.netapps.com.au | +61 (0) 416 062 898 Web Hosting | Internet Services ___ 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: #1024-rework service available
On Wed, 28 Oct 2009 13:04:54 +0100 Davide Scaini dsca...@gmail.com wrote: Hi Michael, i'm also interested in doing teh rework on my own, but on this page http://wiki.openmoko.org/wiki/1024 and related links there are only few images... so can you please post yours when your work is done? Okay I will do that. -- Michael Smith Network Applications www.netapps.com.au | +61 (0) 416 062 898 Web Hosting | Internet Services signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
Michael Smith a écrit : On Wed, 28 Oct 2009 13:04:54 +0100 Davide Scaini dsca...@gmail.com wrote: Hi Michael, i'm also interested in doing teh rework on my own, but on this page http://wiki.openmoko.org/wiki/1024 and related links there are only few images... so can you please post yours when your work is done? Okay I will do that. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community some of mine here in the mess : http://freerunner.daily.free.fr/wp-content/ it was my first attempt with HUGE cap ! (but it worked !) Really easy to do ! Good luck AstHrO ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
On Thu, Oct 22, 2009 at 08:16:59AM +0200, Dr. H. Nikolaus Schaller wrote: How to test if my devices works or needs rework • obtain a command line (e.g. ssh from outside) • open /usr/bin/mickeyterm • type these commands (one after the other) AT+CFUN? AT+CFUN=1 --- only if CFUN? does not report 1 AT+CPIN=insert your pin AT%SLEEP=4 AT%CSQ=1 AT+CREG=2 AT+COPS=0,0 • wait some minutes. If you see +CREG: 0 and/or %CSQ: 99, 99, 0 your device is recamping. here a good device: +CREG: 2 +CREG: 1,033F,5BC4 %CSQ: 13, 99, 1 %CSQ: 7, 99, 0 %CSQ: 10, 99, 1 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 %CSQ: 15, 99, 1 and here a bad device: +CREG: 2 +CREG: 1,033F,2992 %CSQ: 15, 99, 1 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 17, 99, 1 +CREG: 0 Can you give me an estimate of how much and how long it would take to send a fixed freerunner from your place to Portugal? I want to know the total cost before deciding wether to order it from you... Thanks, Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
On Fri, 23 Oct 2009 08:59:06 am Steven ** wrote: Is there someone offering a similar service in the US? Or Australia ? -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
On Fri, 23 Oct 2009 21:05:50 +1100 Chris Samuel ch...@csamuel.org wrote: Or Australia ? Hi. I'm in Melbourne too. Needing to buzz fix an A6 I asked a few electronics engineers. I was looking for somebody who would do delicate soldering work for an hourly rate. The consensus from people I spoke to was that while there are a few small businesses who do electronic work, few would be interested in small jobs. A co-worker of mine offered to do the buzz fix for me. This person tends to over rate his ability. I should have remembered this when I agreed for him to do the work. I plan to tool up and redo the soldering on that phone in the next couple of weeks. The problem with little jobs like this is liability. If he stuffs up, who takes responsibility? On small jobs it is impossible to get insurance. So I am going to do a buzz fix soon. The #1024 fix seems more complicated because you have to disassemble parts of the phone which may be hard to put back together. I might try this procedure on the phone which I am going to do the buzz fix on. I can more afford to stuff that one up. I will post the results here: http://glitch.tl/working_with_shr.html Regards, -- Michael Smith Network Applications www.netapps.com.au | +61 (0) 416 062 898 Web Hosting | Internet Services signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
On 10/22/09, Dr. H. Nikolaus Schaller h...@computer.org wrote: Hi all, some users of Neo Freerunner devices have experienced a limited standby time if the GSM modem goes to the deepest sleep mode. This became known as the #1024 bug, because that was the number it got in the bug tracker (https://docs.openmoko.org/trac/ticket/1024). The software workaround was to disable sleep mode 4 as the default. Although there is a description of a hardware rework solution (http://lists.openmoko.org/pipermail/hardware/2009-May/001192.html ) we do not expect that you can do it yourself. Therefore, we have worked on a professional approach. With the help of a local SMD specialist company in Munich, Golden Delicious Computers can now offer a rework service to those who really suffer from this problem. Price is 45 EUR (incl. German VAT of 19%). If you combine with the Buzz-Rework (for A5 and A6 versions only) it is 75 EUR. And there is a rebate for groups of 5 or 10 units. http://www.handheld-linux.com/wiki.php?page=1024-Rework Nikolaus Conditions • This service is for the EU harmonized market only (sorry for Norway Switzerland) • Customer will send in, get rework and get the device sent back within approx. two weeks • The 2 way shipping cost will be covered by the customer. • When choosing a parcel service, please choose one that allows you to track your parcel since we are not responsible for incoming parcels. For German customers we recommend Hermes-Versand and for UK Royal Mail. • Please pack carefully, but just the Neo Freerunner (without battery, battery cover, headset, pouch, stylus, SIM card, SDcard etc.). We are not responsible for lost accessories - only for the device. We strongly recommend to use the original black box. • In the rare case that we damage your device, you will get a fresh Neo Freerunner (but your data is lost). • If you have several Freerunners to rework, please add as many Reworks as you want to the shopping cart. This will reduce shipment cost compared to several single shipments. And, we offer a volume discount to encourage group buys (5: 5%; 10: 10%; 50: 15%). Rebates are automatically shown in the shopping cart. Important notes • After payment is done, please follow the Rework Instructions (http://www.handheld-linux.com/images/Instructions.pdf ) • Please note that we can handle this service only for customers in the EU harmonized market because temporary import/export is too complicated if we want to avoid that you (or we) have to pay again the import tax for your original Freerunner. • This is not a Bass-Fix: http://wiki.openmoko.org/wiki/GTA02_bass_fix How to test if my devices works or needs rework • obtain a command line (e.g. ssh from outside) • open /usr/bin/mickeyterm • type these commands (one after the other) AT+CFUN? AT+CFUN=1 --- only if CFUN? does not report 1 AT+CPIN=insert your pin AT%SLEEP=4 AT%CSQ=1 AT+CREG=2 AT+COPS=0,0 • wait some minutes. If you see +CREG: 0 and/or %CSQ: 99, 99, 0 your device is recamping. here a good device: +CREG: 2 +CREG: 1,033F,5BC4 %CSQ: 13, 99, 1 %CSQ: 7, 99, 0 %CSQ: 10, 99, 1 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 %CSQ: 15, 99, 1 and here a bad device: +CREG: 2 +CREG: 1,033F,2992 %CSQ: 15, 99, 1 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 17, 99, 1 +CREG: 0 Mobile Office Solutions by Golden Delicious Computers GmbHCo. KG Buchenstr. 3 D-82041 Oberhaching +49-89-54290367 http://www.handheld-linux.com AG München, HRA 89571 VAT DE253626266 Komplementär: Golden Delicious Computers Verwaltungs GmbH Oberhaching, AG München, HRB 16602 Geschäftsführer: Dr. Nikolaus Schaller Digital Tools for Independent People ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Hi, thanks for offering this service! (although too bad I already sent my device once to Germany) can you give us an indication on how much this would improve batterylife? I'm assuming it only extends standby-time. I once saw a graph that indicated that it was a huge boost, but can't find it anymore y ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
Am Freitag, den 23.10.2009, 12:39 +0200 schrieb Yorick Moko: thanks for offering this service! (although too bad I already sent my device once to Germany) can you give us an indication on how much this would improve batterylife? I'm assuming it only extends standby-time. I once saw a graph that indicated that it was a huge boost, but can't find it anymore In optimal conditions, it's going to double your standby time from ~70h to ~140h. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
Hi all, here some answers to recent questions: Q: Rework service for USA, Canada, Australia? A: unfortunately handling import/re-export is too much paperwork and if anything goes wrong, someone might have to pay taxes again. And, shipment is either very slow or much more expensive than within EU. This would make it cheaper to buy a new one... You could ask SDG Systems since they also had organized the Buzz- Rework in Canada, i.e. they have a company capable of doing it. Q: Bass-Rework? A: we currently have no plans because it is again a different work which has to be evaluated, tested, prepared for the public. And demand appears to be lower. Q: how much does it improve? A: here is a report of 143 hours standby time: http://totalueberwachung.de/blog/2009/06/03/freerunner-deep-sleep-standby-time Q: when does GTA02-core or GTA03 come fixing all these issues? A: we don't know either Nikolaus Am 23.10.2009 um 12:39 schrieb Yorick Moko: On 10/22/09, Dr. H. Nikolaus Schaller h...@computer.org wrote: Hi all, some users of Neo Freerunner devices have experienced a limited standby time if the GSM modem goes to the deepest sleep mode. This became known as the #1024 bug, because that was the number it got in the bug tracker (https://docs.openmoko.org/trac/ticket/1024). The software workaround was to disable sleep mode 4 as the default. Although there is a description of a hardware rework solution (http://lists.openmoko.org/pipermail/hardware/2009-May/001192.html ) we do not expect that you can do it yourself. Therefore, we have worked on a professional approach. With the help of a local SMD specialist company in Munich, Golden Delicious Computers can now offer a rework service to those who really suffer from this problem. Price is 45 EUR (incl. German VAT of 19%). If you combine with the Buzz-Rework (for A5 and A6 versions only) it is 75 EUR. And there is a rebate for groups of 5 or 10 units. http://www.handheld-linux.com/wiki.php?page=1024-Rework Nikolaus Conditions • This service is for the EU harmonized market only (sorry for Norway Switzerland) • Customer will send in, get rework and get the device sent back within approx. two weeks • The 2 way shipping cost will be covered by the customer. • When choosing a parcel service, please choose one that allows you to track your parcel since we are not responsible for incoming parcels. For German customers we recommend Hermes-Versand and for UK Royal Mail. • Please pack carefully, but just the Neo Freerunner (without battery, battery cover, headset, pouch, stylus, SIM card, SDcard etc.). We are not responsible for lost accessories - only for the device. We strongly recommend to use the original black box. • In the rare case that we damage your device, you will get a fresh Neo Freerunner (but your data is lost). • If you have several Freerunners to rework, please add as many Reworks as you want to the shopping cart. This will reduce shipment cost compared to several single shipments. And, we offer a volume discount to encourage group buys (5: 5%; 10: 10%; 50: 15%). Rebates are automatically shown in the shopping cart. Important notes • After payment is done, please follow the Rework Instructions (http://www.handheld-linux.com/images/Instructions.pdf ) • Please note that we can handle this service only for customers in the EU harmonized market because temporary import/export is too complicated if we want to avoid that you (or we) have to pay again the import tax for your original Freerunner. • This is not a Bass-Fix: http://wiki.openmoko.org/wiki/GTA02_bass_fix How to test if my devices works or needs rework • obtain a command line (e.g. ssh from outside) • open /usr/bin/mickeyterm • type these commands (one after the other) AT+CFUN? AT+CFUN=1 --- only if CFUN? does not report 1 AT+CPIN=insert your pin AT%SLEEP=4 AT%CSQ=1 AT+CREG=2 AT+COPS=0,0 • wait some minutes. If you see +CREG: 0 and/or %CSQ: 99, 99, 0 your device is recamping. here a good device: +CREG: 2 +CREG: 1,033F,5BC4 %CSQ: 13, 99, 1 %CSQ: 7, 99, 0 %CSQ: 10, 99, 1 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 %CSQ: 15, 99, 1 and here a bad device: +CREG: 2 +CREG: 1,033F,2992 %CSQ: 15, 99, 1 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 17, 99, 1 +CREG: 0 Mobile Office Solutions by Golden Delicious Computers GmbHCo. KG Buchenstr. 3 D-82041 Oberhaching +49-89-54290367 http://www.handheld-linux.com AG München, HRA 89571 VAT DE253626266 Komplementär: Golden Delicious Computers Verwaltungs GmbH Oberhaching, AG München, HRB 16602 Geschäftsführer: Dr. Nikolaus Schaller Digital Tools for Independent People
Re: #1024-rework service available
thanks for offering this service! (although too bad I already sent my device once to Germany) can you give us an indication on how much this would improve batterylife? I'm assuming it only extends standby-time. I once saw a graph that indicated that it was a huge boost, but can't find it anymore Did you mean this pointer: http://totalueberwachung.de/blog/2009/06/03/freerunner-deep-sleep-standby-time ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
On Fri, 23 Oct 2009 13:06:07 +0200 Michael 'Mickey' Lauer mic...@vanille-media.de (M'L) wrote: Am Freitag, den 23.10.2009, 12:39 +0200 schrieb Yorick Moko: thanks for offering this service! (although too bad I already sent my device once to Germany) can you give us an indication on how much this would improve batterylife? I'm assuming it only extends standby-time. I once saw a graph that indicated that it was a huge boost, but can't find it anymore In optimal conditions, it's going to double your standby time from ~70h to ~140h. During first live tests this week, qtmoko managed to last two full days (plus nights) of quite a bit of calls and messaging with occasional checking of status, gprs connection andgps. Previously, one day of use would drain the battery so this is an improvement. As the testing is subjective to usage, we will see in the near future what the real stand by time might be. Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
On Fri, Oct 23, 2009 at 1:07 PM, Dr. H. Nikolaus Schaller h...@computer.org wrote: Q: Bass-Rework? A: we currently have no plans because it is again a different work which has to be evaluated, tested, prepared for the public. And demand appears to be lower. But having bass rework the same time as the 1024 fix, its a huge benefit and also more attractive service. I for example will never send my phone for just to the #1024 fix, because I plan to in a way or another apply the bass fix. So no point to sending you to do the half of the job. (the easier half actually) Frankly, when you dismounted the phone, and you have the necessary tools in your hand, than applying the bass rework in plus, is a negligible price In my really biased view, I find ugly to coming up each quarter year to provide a separate fix, and thus requireing people to send you their freerunner multiple times... ((also I find not fair to having the two fix together involves almost the double price, as it does not require double amount of work)) Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
Am 23.10.2009 um 13:21 schrieb Laszlo KREKACS: On Fri, Oct 23, 2009 at 1:07 PM, Dr. H. Nikolaus Schaller h...@computer.org wrote: Q: Bass-Rework? A: we currently have no plans because it is again a different work which has to be evaluated, tested, prepared for the public. And demand appears to be lower. But having bass rework the same time as the 1024 fix, its a huge benefit and also more attractive service. I for example will never send my phone for just to the #1024 fix, because I plan to in a way or another apply the bass fix. So no point to sending you to do the half of the job. (the easier half actually) Frankly, when you dismounted the phone, and you have the necessary tools in your hand, than applying the bass rework in plus, is a negligible price No. You have to open a different tin can. You have to cut and solder different cables. The test procedure is different. We want to make sure that every fix we offer really works, is reproducible and has high quality. Therfore, it is not just doing the same thing again. The common work is of course the logistics which is done only once. In my really biased view, I find ugly to coming up each quarter year to provide a separate fix, and thus requireing people to send you their freerunner multiple times... Nobody is required to ask for the reworks at all... ((also I find not fair to having the two fix together involves almost the double price, as it does not require double amount of work)) We are a community. Therfore, you are free (and I hope open) to come up with your own, cheaper offers... Nikolaus Best regards, Laszlo ___ 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: #1024-rework service available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. H. Nikolaus Schaller schrieb: Am 23.10.2009 um 13:21 schrieb Laszlo KREKACS: On Fri, Oct 23, 2009 at 1:07 PM, Dr. H. Nikolaus Schaller h...@computer.org wrote: Q: Bass-Rework? A: we currently have no plans because it is again a different work which has to be evaluated, tested, prepared for the public. And demand appears to be lower. But having bass rework the same time as the 1024 fix, its a huge benefit and also more attractive service. I for example will never send my phone for just to the #1024 fix, because I plan to in a way or another apply the bass fix. So no point to sending you to do the half of the job. (the easier half actually) Frankly, when you dismounted the phone, and you have the necessary tools in your hand, than applying the bass rework in plus, is a negligible price No. You have to open a different tin can. You have to cut and solder different cables. The test procedure is different. We want to make sure that every fix we offer really works, is reproducible and has high quality. Therfore, it is not just doing the same thing again. The common work is of course the logistics which is done only once. In my really biased view, I find ugly to coming up each quarter year to provide a separate fix, and thus requireing people to send you their freerunner multiple times... Nobody is required to ask for the reworks at all... ((also I find not fair to having the two fix together involves almost the double price, as it does not require double amount of work)) We are a community. Therfore, you are free (and I hope open) to come up with your own, cheaper offers... Nikolaus Best regards, Laszlo ___ 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 Have any effords been done to prepare a bass-fix? Can you guess a date where and if you will offer it? When it will be offered I would prefer to let both be fixed. Greeti+ngs Bastian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK4cNmlYiDScJJ+7QRAghCAJ4id8XY0jvNiiS4JJ64hozNjfmOcQCgxGmI UDej8HKJjUbL+RWSu9bwrSM= =K9Pi -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
#1024-rework service available
Hi all, some users of Neo Freerunner devices have experienced a limited standby time if the GSM modem goes to the deepest sleep mode. This became known as the #1024 bug, because that was the number it got in the bug tracker (https://docs.openmoko.org/trac/ticket/1024). The software workaround was to disable sleep mode 4 as the default. Although there is a description of a hardware rework solution (http://lists.openmoko.org/pipermail/hardware/2009-May/001192.html ) we do not expect that you can do it yourself. Therefore, we have worked on a professional approach. With the help of a local SMD specialist company in Munich, Golden Delicious Computers can now offer a rework service to those who really suffer from this problem. Price is 45 EUR (incl. German VAT of 19%). If you combine with the Buzz-Rework (for A5 and A6 versions only) it is 75 EUR. And there is a rebate for groups of 5 or 10 units. http://www.handheld-linux.com/wiki.php?page=1024-Rework Nikolaus Conditions • This service is for the EU harmonized market only (sorry for Norway Switzerland) • Customer will send in, get rework and get the device sent back within approx. two weeks • The 2 way shipping cost will be covered by the customer. • When choosing a parcel service, please choose one that allows you to track your parcel since we are not responsible for incoming parcels. For German customers we recommend Hermes-Versand and for UK Royal Mail. • Please pack carefully, but just the Neo Freerunner (without battery, battery cover, headset, pouch, stylus, SIM card, SDcard etc.). We are not responsible for lost accessories - only for the device. We strongly recommend to use the original black box. • In the rare case that we damage your device, you will get a fresh Neo Freerunner (but your data is lost). • If you have several Freerunners to rework, please add as many Reworks as you want to the shopping cart. This will reduce shipment cost compared to several single shipments. And, we offer a volume discount to encourage group buys (5: 5%; 10: 10%; 50: 15%). Rebates are automatically shown in the shopping cart. Important notes • After payment is done, please follow the Rework Instructions (http://www.handheld-linux.com/images/Instructions.pdf ) • Please note that we can handle this service only for customers in the EU harmonized market because temporary import/export is too complicated if we want to avoid that you (or we) have to pay again the import tax for your original Freerunner. • This is not a Bass-Fix: http://wiki.openmoko.org/wiki/GTA02_bass_fix How to test if my devices works or needs rework • obtain a command line (e.g. ssh from outside) • open /usr/bin/mickeyterm • type these commands (one after the other) AT+CFUN? AT+CFUN=1 --- only if CFUN? does not report 1 AT+CPIN=insert your pin AT%SLEEP=4 AT%CSQ=1 AT+CREG=2 AT+COPS=0,0 • wait some minutes. If you see +CREG: 0 and/or %CSQ: 99, 99, 0 your device is recamping. here a good device: +CREG: 2 +CREG: 1,033F,5BC4 %CSQ: 13, 99, 1 %CSQ: 7, 99, 0 %CSQ: 10, 99, 1 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 %CSQ: 15, 99, 1 and here a bad device: +CREG: 2 +CREG: 1,033F,2992 %CSQ: 15, 99, 1 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 17, 99, 1 +CREG: 0 Mobile Office Solutions by Golden Delicious Computers GmbHCo. KG Buchenstr. 3 D-82041 Oberhaching +49-89-54290367 http://www.handheld-linux.com AG München, HRA 89571 VAT DE253626266 Komplementär: Golden Delicious Computers Verwaltungs GmbH Oberhaching, AG München, HRB 16602 Geschäftsführer: Dr. Nikolaus Schaller Digital Tools for Independent People ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
Am 22.10.2009 um 12:48 schrieb George Brooke: On Thursday 22 Oct 2009 07:16:59 Dr. H. Nikolaus Schaller wrote: Hi all, some users of Neo Freerunner devices have experienced a limited standby time if the GSM modem goes to the deepest sleep mode. This became known as the #1024 bug, because that was the number it got in the bug tracker (https://docs.openmoko.org/trac/ticket/1024). The software workaround was to disable sleep mode 4 as the default. Although there is a description of a hardware rework solution (http://lists.openmoko.org/pipermail/hardware/2009-May/ 001192.html ) we do not expect that you can do it yourself. Therefore, we have worked on a professional approach. With the help of a local SMD specialist company in Munich, Golden Delicious Computers can now offer a rework service to those who really suffer from this problem. Price is 45 EUR (incl. German VAT of 19%). If you combine with the Buzz-Rework (for A5 and A6 versions only) it is 75 EUR. And there is a rebate for groups of 5 or 10 units. http://www.handheld-linux.com/wiki.php?page=1024-Rework Nikolaus Conditions • This service is for the EU harmonized market only (sorry for Norway Switzerland) • Customer will send in, get rework and get the device sent back within approx. two weeks • The 2 way shipping cost will be covered by the customer. • When choosing a parcel service, please choose one that allows you to track your parcel since we are not responsible for incoming parcels. For German customers we recommend Hermes-Versand and for UK Royal Mail. • Please pack carefully, but just the Neo Freerunner (without battery, battery cover, headset, pouch, stylus, SIM card, SDcard etc.). We are not responsible for lost accessories - only for the device. We strongly recommend to use the original black box. • In the rare case that we damage your device, you will get a fresh Neo Freerunner (but your data is lost). • If you have several Freerunners to rework, please add as many Reworks as you want to the shopping cart. This will reduce shipment cost compared to several single shipments. And, we offer a volume discount to encourage group buys (5: 5%; 10: 10%; 50: 15%). Rebates are automatically shown in the shopping cart. Important notes • After payment is done, please follow the Rework Instructions (http://www.handheld-linux.com/images/Instructions.pdf ) • Please note that we can handle this service only for customers in the EU harmonized market because temporary import/export is too complicated if we want to avoid that you (or we) have to pay again the import tax for your original Freerunner. • This is not a Bass-Fix: http://wiki.openmoko.org/wiki/GTA02_bass_fix How to test if my devices works or needs rework • obtain a command line (e.g. ssh from outside) • open /usr/bin/mickeyterm • type these commands (one after the other) AT+CFUN? AT+CFUN=1 --- only if CFUN? does not report 1 AT+CPIN=insert your pin AT%SLEEP=4 AT%CSQ=1 AT+CREG=2 AT+COPS=0,0 • wait some minutes. If you see +CREG: 0 and/or %CSQ: 99, 99, 0 your device is recamping. here a good device: +CREG: 2 +CREG: 1,033F,5BC4 %CSQ: 13, 99, 1 %CSQ: 7, 99, 0 %CSQ: 10, 99, 1 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 %CSQ: 15, 99, 1 and here a bad device: +CREG: 2 +CREG: 1,033F,2992 %CSQ: 15, 99, 1 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 17, 99, 1 +CREG: 0 Do you need to enable deep sleep mode before doing the test? I think the command AT%SLEEP=4 enables the deep sleep of the modem. Also is this a time-limited service? No, we offer it as long as there is demand. Well, nobody knows what we can provide in 10 or 20 years :) And if we extrapolate technology innovation you probably won't be interested then... solar.george ___ 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: #1024-rework service available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. H. Nikolaus Schaller schrieb: Hi all, some users of Neo Freerunner devices have experienced a limited standby time if the GSM modem goes to the deepest sleep mode. This became known as the #1024 bug, because that was the number it got in the bug tracker (https://docs.openmoko.org/trac/ticket/1024). The software workaround was to disable sleep mode 4 as the default. Although there is a description of a hardware rework solution (http://lists.openmoko.org/pipermail/hardware/2009-May/001192.html ) we do not expect that you can do it yourself. Therefore, we have worked on a professional approach. With the help of a local SMD specialist company in Munich, Golden Delicious Computers can now offer a rework service to those who really suffer from this problem. Price is 45 EUR (incl. German VAT of 19%). If you combine with the Buzz-Rework (for A5 and A6 versions only) it is 75 EUR. And there is a rebate for groups of 5 or 10 units. http://www.handheld-linux.com/wiki.php?page=1024-Rework Nikolaus Conditions • This service is for the EU harmonized market only (sorry for Norway Switzerland) • Customer will send in, get rework and get the device sent back within approx. two weeks • The 2 way shipping cost will be covered by the customer. • When choosing a parcel service, please choose one that allows you to track your parcel since we are not responsible for incoming parcels. For German customers we recommend Hermes-Versand and for UK Royal Mail. • Please pack carefully, but just the Neo Freerunner (without battery, battery cover, headset, pouch, stylus, SIM card, SDcard etc.). We are not responsible for lost accessories - only for the device. We strongly recommend to use the original black box. • In the rare case that we damage your device, you will get a fresh Neo Freerunner (but your data is lost). • If you have several Freerunners to rework, please add as many Reworks as you want to the shopping cart. This will reduce shipment cost compared to several single shipments. And, we offer a volume discount to encourage group buys (5: 5%; 10: 10%; 50: 15%). Rebates are automatically shown in the shopping cart. Important notes • After payment is done, please follow the Rework Instructions (http://www.handheld-linux.com/images/Instructions.pdf ) • Please note that we can handle this service only for customers in the EU harmonized market because temporary import/export is too complicated if we want to avoid that you (or we) have to pay again the import tax for your original Freerunner. • This is not a Bass-Fix: http://wiki.openmoko.org/wiki/GTA02_bass_fix How to test if my devices works or needs rework • obtain a command line (e.g. ssh from outside) • open /usr/bin/mickeyterm • type these commands (one after the other) AT+CFUN? AT+CFUN=1 --- only if CFUN? does not report 1 AT+CPIN=insert your pin AT%SLEEP=4 AT%CSQ=1 AT+CREG=2 AT+COPS=0,0 • wait some minutes. If you see +CREG: 0 and/or %CSQ: 99, 99, 0 your device is recamping. here a good device: +CREG: 2 +CREG: 1,033F,5BC4 %CSQ: 13, 99, 1 %CSQ: 7, 99, 0 %CSQ: 10, 99, 1 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 %CSQ: 15, 99, 1 and here a bad device: +CREG: 2 +CREG: 1,033F,2992 %CSQ: 15, 99, 1 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 18, 99, 2 +CREG: 0 %CSQ: 99, 99, 0 +CREG: 1,033F,2992 %CSQ: 17, 99, 1 +CREG: 0 Mobile Office Solutions by Golden Delicious Computers GmbHCo. KG Buchenstr. 3 D-82041 Oberhaching +49-89-54290367 http://www.handheld-linux.com AG München, HRA 89571 VAT DE253626266 Komplementär: Golden Delicious Computers Verwaltungs GmbH Oberhaching, AG München, HRB 16602 Geschäftsführer: Dr. Nikolaus Schaller Digital Tools for Independent People ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community That are great news. I guess that I will buy the rework. Greetungs Bastian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK4IgklYiDScJJ+7QRAuuOAJ93sAosN+Dqd5gIUQ5q6dSoMB96fgCgzzNI g3ZU3NZSLHa+4vSBPFnyvtI= =Komc -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
Dr.H.NikolausS wrote: • This is not a Bass-Fix: http://wiki.openmoko.org/wiki/GTA02_bass_fix Is this planned in the future? I'd like to buy all the fixes at once... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
On Thu, Oct 22, 2009 at 1:16 AM, Dr. H. Nikolaus Schaller h...@computer.org wrote: Hi all, Conditions • This service is for the EU harmonized market only (sorry for Norway Switzerland) So, this excludes US customers? Is there someone offering a similar service in the US? Thanks, Steven ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: #1024-rework service available
|-Original Message- |From: community-boun...@lists.openmoko.org [mailto:community- |boun...@lists.openmoko.org] On Behalf Of Steven ** |Sent: Thursday, October 22, 2009 2:59 PM |To: List for Openmoko community discussion |Subject: Re: #1024-rework service available | |On Thu, Oct 22, 2009 at 1:16 AM, Dr. H. Nikolaus Schaller |h...@computer.org wrote: | Hi all, | | Conditions | |. This service is for the EU harmonized market only (sorry for |Norway | Switzerland) | |So, this excludes US customers? | |Is there someone offering a similar service in the US? | |Thanks, |Steven +1 [Russell Dwiggins] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
On Thu, Oct 22, 2009 at 11:04:33PM +0200, Marco Trevisan (Treviño) wrote: Dr.H.NikolausS wrote: ??? This is not a Bass-Fix: http://wiki.openmoko.org/wiki/GTA02_bass_fix Is this planned in the future? I'd like to buy all the fixes at once... Me too. My freerunner happily went to Germany once but I don't want to make him sad with too much travelling :-( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
Framework not being able to open a new channel means fso-abyss is not able to register a channel with the multiplexer. That it only works 4 out of 5 times sounds like a race condition. Do you have anything else installed that could compete with fso-abyss over the GSM resource? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
Hi, Michael 'Mickey' Lauer-2 wrote: Do you have anything else installed that could compete with fso-abyss over the GSM resource? Like what? I'm not all that clear about the multiplexing process. As far as I know I have only the latest version of shr-u installed with all the upgrades (and waiting for more :) I do have gsm0710muxd installed - but from what I see - only fso-abyss is started up in the log. I have attached the log where the phone registers to this mail. Will post the log where the modem doesn't register in a few hours - when I can use another phone instead. Thanks. [working] http://n2.nabble.com/file/n3857557/frameworkd.log frameworkd.log [not working] -- View this message in context: http://n2.nabble.com/GSM-errors-after-1024-fix-tp3827146p3857557.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: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
On Mon, 19 Oct 2009 01:50:51 -0400 David Ford da...@blue-labs.org (DF) wrote: actually i was vague/misleading in what i wrote. what i would like to see is for the end user to be notified in a friendly fashion. like injecting a service message into opimd/sms buffer sounds like a good communication method for the future :), if the devs like it :)) Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
Am Montag, den 19.10.2009, 12:46 +0200 schrieb Petr Vanek: On Mon, 19 Oct 2009 01:50:51 -0400 David Ford da...@blue-labs.org (DF) wrote: actually i was vague/misleading in what i wrote. what i would like to see is for the end user to be notified in a friendly fashion. like injecting a service message into opimd/sms buffer sounds like a good communication method for the future :), if the devs like it :)) I'm open for it. I find sending a dbus signal somewhat less intrusive though... :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
On Mon, 19 Oct 2009 17:15:18 +0200 Michael 'Mickey' Lauer mic...@vanille-media.de (M'L) wrote: Am Montag, den 19.10.2009, 12:46 +0200 schrieb Petr Vanek: On Mon, 19 Oct 2009 01:50:51 -0400 David Ford da...@blue-labs.org (DF) wrote: actually i was vague/misleading in what i wrote. what i would like to see is for the end user to be notified in a friendly fashion. like injecting a service message into opimd/sms buffer sounds like a good communication method for the future :), if the devs like it :)) I'm open for it. I find sending a dbus signal somewhat less intrusive though... as everything, it would have to be configurable and well thought through :) is there a difference between a SMS message and another type of message? Also, could a message contain an attachment? i.e. bluetooth received file? or how about a link to the file... this would then be dependent on the ability of the viewer i guess... Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
Hi, Well, I got mr FR rechecked and it seems that the fix was applied fine. But - I still have this problem. About 4 out of 5 times my FR fails to register with the messages like 2009.10.15 07:29:57.870 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:29:57.880 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:11.55 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:30:11.65 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:24.375 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:30:24.502 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' and this continues with no registration. I need to restart and sometimes it registers fine. 1. Can someone tell me what this means? 2. I tried android's latest release and surprisingly, the modem registered fine immediately! Is this a new bug? :( I'm on roaming - if that makes any diff - but I'm surprised how fast the newer version of android boots up and registers (with a small r to indicate the roaming status)!! shr-u on the other hand takes 4 tries or so to register successfully. Seems to be a software prob in my opinion now - but I can't confirm that without more help. Mickey - can you shed some light on the error messages? -- View this message in context: http://n2.nabble.com/GSM-errors-after-1024-fix-tp3827146p3856574.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: 1024#
I've been wondering if all the freerunners are affected by bug #1024? Most of GTA02-A5/A6 have this bug. Once TI_CALYPSO_DEEP_SLEEP set to always, you can check with a little script done by KaZEr (see bleow) Launch it on screen, and redirect output to a file. If you have something like [2009-09-09 12:36:09.189663] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:36:15.088936] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:38:10.442808] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:38:13.020126] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:40:25.772918] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:40:28.620096] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:41:17.557676] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:41:20.404582] Signal : cid=3BB3, lac=0D48 hi, one thing is still not clear to me. When you run the test script, should the freerunner be suspended or awake? I tried both and cannot see any output from the script, not even during driving, when cells do change. My fr clearly had the issue (i was missing a lots of calls with Qtopia, before disabling deep sleep was implementing... I think i am done with summarizing of all this, please check and eventually correct: http://wiki.openmoko.org/wiki/1024 Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
Hi, I get messages like [2009-10-18 07:51:27.107655] Signal : cid=4E91, lac=006A [2009-10-18 07:52:45.145288] Signal : cid=4E7B, lac=006A [2009-10-18 07:53:18.218122] Signal : cid=4E91, lac=006A ... So I guess my #1024 is not fixed :-( The three lines you quoted are not showing #1024. Again, frequent cell _handovers_ are perfectly normal. #1024 is about dropping out of a cell, then recamping into it, e.g. it looks like that: [2009-10-18 07:51:27.107655] Signal : cid=4E91, lac=006A [2009-10-18 07:52:45.145288] Signal : cid=4E91, lac=006A [2009-10-18 07:53:18.218122] Signal : cid=4E91, lac=006A (NB: This compact debug output form is not optimal for recognizing #1024 anyways, you should rather watch for CSQ and CREG messages. If CSQ suddenly drops to 99 and you get thrown out of the cell, then it's 100% clear you have #1024). :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
I get messages like [2009-10-18 07:51:27.107655] Signal : cid=4E91, lac=006A [2009-10-18 07:52:45.145288] Signal : cid=4E7B, lac=006A [2009-10-18 07:53:18.218122] Signal : cid=4E91, lac=006A ... So I guess my #1024 is not fixed :-( The three lines you quoted are not showing #1024. Again, frequent cell _handovers_ are perfectly normal. #1024 is about dropping out of a cell, then recamping into it, e.g. it looks like that: [2009-10-18 07:51:27.107655] Signal : cid=4E91, lac=006A [2009-10-18 07:52:45.145288] Signal : cid=4E91, lac=006A [2009-10-18 07:53:18.218122] Signal : cid=4E91, lac=006A (NB: This compact debug output form is not optimal for recognizing #1024 anyways, you should rather watch for CSQ and CREG messages. If CSQ suddenly drops to 99 and you get thrown out of the cell, then it's 100% clear you have #1024). How about this output: [2009-10-18 13:37:02.701925] Signal : cid=9E4A, lac=17A2 [2009-10-18 13:37:26.813505] Signal : cid=7149, lac=17A2 [2009-10-18 13:41:22.576405] Signal : cid=9E4A, lac=17A2 [2009-10-18 13:45:48.512750] Signal : cid=7149, lac=17A2 [2009-10-18 13:49:10.453532] Signal : cid=9E4A, lac=17A2 If there is a better way - script of determining whether the 1024 has been dealt with correctly, it would be helpful... thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
On 10/18/09, Petr Vanek van...@penguin.cz wrote: I get messages like [2009-10-18 07:51:27.107655] Signal : cid=4E91, lac=006A [2009-10-18 07:52:45.145288] Signal : cid=4E7B, lac=006A [2009-10-18 07:53:18.218122] Signal : cid=4E91, lac=006A ... So I guess my #1024 is not fixed :-( The three lines you quoted are not showing #1024. Again, frequent cell _handovers_ are perfectly normal. #1024 is about dropping out of a cell, then recamping into it, e.g. it looks like that: [2009-10-18 07:51:27.107655] Signal : cid=4E91, lac=006A [2009-10-18 07:52:45.145288] Signal : cid=4E91, lac=006A [2009-10-18 07:53:18.218122] Signal : cid=4E91, lac=006A (NB: This compact debug output form is not optimal for recognizing #1024 anyways, you should rather watch for CSQ and CREG messages. If CSQ suddenly drops to 99 and you get thrown out of the cell, then it's 100% clear you have #1024). How about this output: [2009-10-18 13:37:02.701925] Signal : cid=9E4A, lac=17A2 [2009-10-18 13:37:26.813505] Signal : cid=7149, lac=17A2 [2009-10-18 13:41:22.576405] Signal : cid=9E4A, lac=17A2 [2009-10-18 13:45:48.512750] Signal : cid=7149, lac=17A2 [2009-10-18 13:49:10.453532] Signal : cid=9E4A, lac=17A2 If there is a better way - script of determining whether the 1024 has been dealt with correctly, it would be helpful... thank you Petr Looks normally, not like #1024. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
How about this output: [2009-10-18 13:37:02.701925] Signal : cid=9E4A, lac=17A2 [2009-10-18 13:37:26.813505] Signal : cid=7149, lac=17A2 [2009-10-18 13:41:22.576405] Signal : cid=9E4A, lac=17A2 [2009-10-18 13:45:48.512750] Signal : cid=7149, lac=17A2 [2009-10-18 13:49:10.453532] Signal : cid=9E4A, lac=17A2 No recamping either, just handovers. If there is a better way - script of determining whether the 1024 has been dealt with correctly, it would be helpful... Yes, just use frameworkd with ti_calypso_sleep_mode = 'adaptive' and inspect the logs. Frameworkd will tell you, when a real recamping exists. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
Yes, just use frameworkd with ti_calypso_sleep_mode = 'adaptive' and inspect the logs. Frameworkd will tell you, when a real recamping exists. makes sense, thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
How did you ever get it to work in the first place? I noticed the Debian package appearing and installed it, but never found all of the required documentation to actually use it: i don't remember exactly, but i think the only change was setting the muxer to fso-abyss in frameworkd.conf. [snip] after several frameworkd restarts and two reboots i decided to revert to gsmwhtsitsnamemuxer, which seems to work far better Where 'far better' means crashes at the slightest provocation (such as (trying to) ping across a GPRS connection). well, yeah. once a month i get a call -- and it happened, when using gsmwhatsitsnamemuxer. fr rang but i couldn't pick up :-( switched back to fso-abyss, which loses connection on resume -- no calls at all. for the time being i switched to shr-u, which i flashed last time my debian/fso broke. at least telephony is working so far. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
can't we build in detection for that? Michael 'Mickey' Lauer wrote: (NB: This compact debug output form is not optimal for recognizing #1024 anyways, you should rather watch for CSQ and CREG messages. If CSQ suddenly drops to 99 and you get thrown out of the cell, then it's 100% clear you have #1024). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
On Mon, 19 Oct 2009 00:32:28 -0400 David Ford da...@blue-labs.org (DF) wrote: can't we build in detection for that? Michael 'Mickey' Lauer wrote: (NB: This compact debug output form is not optimal for recognizing #1024 anyways, you should rather watch for CSQ and CREG messages. If CSQ suddenly drops to 99 and you get thrown out of the cell, then it's 100% clear you have #1024). It exists already. ...another way is to use frameworkd with ti_calypso_sleep_mode = 'adaptive' and inspect the logs. Frameworkd will tell you, when a real recamping exists. http://wiki.openmoko.org/wiki/1024#Bug_detection -- Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
actually i was vague/misleading in what i wrote. what i would like to see is for the end user to be notified in a friendly fashion. like injecting a service message into opimd/sms buffer Petr Vanek wrote: It exists already. ...another way is to use frameworkd with ti_calypso_sleep_mode = 'adaptive' and inspect the logs. Frameworkd will tell you, when a real recamping exists. http://wiki.openmoko.org/wiki/1024#Bug_detection ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
Hi, I get messages like [2009-10-18 07:51:27.107655] Signal : cid=4E91, lac=006A [2009-10-18 07:52:45.145288] Signal : cid=4E7B, lac=006A [2009-10-18 07:53:18.218122] Signal : cid=4E91, lac=006A ... So I guess my #1024 is not fixed :-( -- View this message in context: http://n2.nabble.com/GSM-errors-after-1024-fix-tp3827146p3842955.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: #1024-Fix in switzerland
The #1024-fix in switzerland is organized: Art.Nr.Artikel: GTA01-02FIX1024Openmoko GTA01 and GTA02 hardware-fix (Replacing the 10uF capacitor with a new high value 22uF capacitor) Price:42.00 CHF Additional costs: S99943 Versandkostenanteil PDA 19.00 CHF (CH) all prices without MwST. You may order the fix under the aforementioned art.-number. It'll take 1-2 day to perform the fix. SwissIT Repair AG Bahnhofstrasse 50 CH-5507 Mellingen Tel. +41-(0)58 556 01 02 Direkt Tel. +41-(0)58 556 01 01 Auftragscenter Tel. +41-(0)58 556 01 07 Ersatzteilhandel (Fragen zu Bestellungen) Fax.+41-(0)58 556 01 09 Telefax http://www.swissitrepair.ch Info: i...@swissitrepair.ch I'm not related with this company, so direct any question to i...@swissitrepair.ch cheers itman Am 12.10.2009 22:13, schrieb DRSp.: dear list, I'm about organizing a #1024-fix-party just without the party-part 'cos there's a IT-firm involved. to get a rough idea about how many FR's are to be fixed, drop a message in this list. cheers itman ___ 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: #1024-Fix in switzerland
Le Fri, 16 Oct 2009 11:11:47 +0200, DRSp. it...@gmx.net a écrit : The #1024-fix in switzerland is organized: Art.Nr.Artikel: GTA01-02FIX1024Openmoko GTA01 and GTA02 hardware-fix (Replacing the 10uF capacitor with a new high value 22uF capacitor) Price:42.00 CHF Additional costs: S99943 Versandkostenanteil PDA 19.00 CHF (CH) all prices without MwST. You may order the fix under the aforementioned art.-number. It'll take 1-2 day to perform the fix. SwissIT Repair AG Bahnhofstrasse 50 CH-5507 Mellingen Tel. +41-(0)58 556 01 02 Direkt Tel. +41-(0)58 556 01 01 Auftragscenter Tel. +41-(0)58 556 01 07 Ersatzteilhandel (Fragen zu Bestellungen) Fax.+41-(0)58 556 01 09 Telefax http://www.swissitrepair.ch Info: i...@swissitrepair.ch I'm not related with this company, so direct any question to i...@swissitrepair.ch Thanks ! And about the other fixes as well ? (buzz, bass and GPS / SDIO issue) Best regards -- Alexandre Ghisoli ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 1024#
O Then you have the bug (trying to connect to GSM every second!) What would be considered a normal rate of connections? Under normal circumstances you would only see these messages with a change of cell, so cid would be different. The only time I know of that you might legitimately see repeated reconnection to the same cell is if you've got very low signal and it's the only cell visible. I get intermittent reconnection problems where the gap between reconnections is between 15s and several hours. i have one fr here with the 1024 fix already done but i can not see any output even during car ride, when cells do change for sure... is the script really working OK? thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-Fix in switzerland
On Friday 16 October 2009, Alexandre Ghisoli wrote: And about the other fixes as well ? (buzz, bass and GPS / SDIO issue) How many times does it need to be said? THERE IS NO GPS/SDIO ISSUE ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
On Thu, Oct 15, 2009 at 12:48:50PM +0200, arne anka wrote: try the other muxer, gsmwhatsitsname, instead. to me it seems, fso-abyss has detoriated into almost unusability over the last months. How did you ever get it to work in the first place? I noticed the Debian package appearing and installed it, but never found all of the required documentation to actually use it: 1) D-bus path. 2) D-bus destination. 3) D-bus this-third-thing-dbus-send-etc-needs-to-know. 4) The interface specification. [snip] after several frameworkd restarts and two reboots i decided to revert to gsmwhtsitsnamemuxer, which seems to work far better Where 'far better' means crashes at the slightest provocation (such as (trying to) ping across a GPRS connection). My only motivation for installing fso-abyss in the first place was to get multiplexed GPRS working (again - I think it did work back in December or January). :-( -- 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: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
http://www.freesmartphone.org/index.php/Implementations/fso-abyss. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM errors after 1024 fix
rakshat wrote: Did u manage to register at all after the fix? Or the error started later? Seems like I can register once in every 4/5 reboots. I'm registered now after 5 reboots. -- View this message in context: http://n2.nabble.com/GSM-errors-after-1024-fix-tp3827146p3827502.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: GSM errors after 1024 fix
try the other muxer, gsmwhatsitsname, instead. to me it seems, fso-abyss has detoriated into almost unusability over the last months. when is started with it, month ago, it worked flawlessly, after doing an update to a more recent version of fso in july/august, zhone had issues requesting the gsm once in a while. i updated to the latest fso packages of debian tuesday and zhone would not connect to fso at all -- something about not being able to enable gsm, gsm being in state enabling or to that effect. before, i could restart frameworkd and it worked, last resort was reboot. after several frameworkd restarts and two reboots i decided to revert to gsmwhtsitsnamemuxer, which seems to work far better (though with some minor flaws. connection to network is sometimes lost and i need to call twice to actually call). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM errors after 1024 fix
have you changed the deep sleep mode setting? or have you done an opkg update after the fix? if yes can you revert back and check. also check if recamping has stopped after the fix - just to be sure the fix was ok. On 10/15/09, c_c cchan...@yahoo.com wrote: rakshat wrote: Did u manage to register at all after the fix? Or the error started later? Seems like I can register once in every 4/5 reboots. I'm registered now after 5 reboots. -- View this message in context: http://n2.nabble.com/GSM-errors-after-1024-fix-tp3827146p3827502.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 -- -- Please use Firefox as your web browser. Its protects you from spyware and is also a very feature rich browser. www.firefox.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM errors after 1024 fix
Am Donnerstag, den 15.10.2009, 12:48 +0200 schrieb arne anka: try the other muxer, gsmwhatsitsname, instead. to me it seems, fso-abyss has detoriated into almost unusability over the last months. Wow, that'd be quite an achiement considering that I didn't do any development on it. Note that it still works flawlessly here. Perhaps software these days starts to rot, just as organic material ;) :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM errors after 1024 fix
Wow, that'd be quite an achiement considering that I didn't do any development on it. Note that it still works flawlessly here. Perhaps software these days starts to rot, just as organic material ;) well, debian's release cycle is somewhat detached from upstream. i don't know when you did any development on it last. i am perfectly open to any suggestion how to make it work again, but so far i am stuck -- and since the fr is my sole phone it has to work most of the day. tried two different frameworkd.conf, mine, so far working, and one posted on the list (smartphone-userland, iirc) said to be working well as well. the issues with fso-abyss remained regardless. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM errors after 1024 fix
Hi, Well, mine is working for now. I managed to reboot it to show android to a friend - and it registered both in android and in shr-u - after I 'thumped' it a few times ;-) It might be because of some loose connection - I intend getting it checked soon - just need some time from pending stuff. Definitely a hardware problem - unless 'organic' software starts responding to thumping too ;-) BTW - I did switch the modem to 'always' and there haven't been any updates to shr-u for a long time now - so the software is the same as before the buzz fix. Somehow, I can't seem to notice any significant increase in the battery standby time either. How do I check for the modem recamping? -- View this message in context: http://n2.nabble.com/GSM-errors-after-1024-fix-tp3827146p3833238.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: #1024-Fix in switzerland
Hello, I am interested too. Thanks Adrian ursprüngliche Nachricht- Von: Alexandre Ghisoli a...@ghisoli.ch An: community@lists.openmoko.org Datum: Tue, 13 Oct 2009 14:37:17 +0200 - Le Mon, 12 Oct 2009 22:13:05 +0200, DRSp. it...@gmx.net a écrit : dear list, I'm about organizing a #1024-fix-party just without the party-part 'cos there's a IT-firm involved. to get a rough idea about how many FR's are to be fixed, drop a message in this list. cheers itman ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I'm ! And all other hardware bug (capacitor, ..) Thanks -- Alexandre Ghisoli ___ 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: #1024-Fix in switzerland
On 12.10.2009 22:13, DRSp. wrote: I'm about organizing a #1024-fix-party just without the party-part 'cos there's a IT-firm involved. to get a rough idea about how many FR's are to be fixed, drop a message in this list. I'm interested too. Regards Christian smime.p7s Description: S/MIME Cryptographic Signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-Fix in switzerland
Hi Itman to get a rough idea about how many FR's are to be fixed, drop a message in this list. Thank you for the organization. I am very interested. Best Sam ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-Fix in switzerland
Petr Vanek wrote: [...] As mentioned previously, we would test on one piece first, confirm, then we would run the test script on all three pieces done. BTW, you can see how he has done the buzz fix for us (sleek design in placing the cap) and has taken a few shots on his work photo microscope: http://vanous.penguin.cz/files/om/SOP/ Assuming this works out well - what fixes are you going to offer? All 3 (buzz, #1024, bass)? Or the first two? Will it be possible to send in a phone from Norway? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-Fix in switzerland
Petr Vanek wrote: [...] As mentioned previously, we would test on one piece first, confirm, then we would run the test script on all three pieces done. BTW, you can see how he has done the buzz fix for us (sleek design in placing the cap) and has taken a few shots on his work photo microscope: http://vanous.penguin.cz/files/om/SOP/ Assuming this works out well - what fixes are you going to offer? All 3 (buzz, #1024, bass)? Or the first two? Will it be possible to send in a phone from Norway? Let me check with the guy as i don't think we could make this in large scale due to time constrains at his side... I will let you know, Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-Fix in switzerland
Le lundi 12 octobre 2009 à 22:13 +0200, DRSp. a écrit : dear list, I'm about organizing a #1024-fix-party just without the party-part 'cos there's a IT-firm involved. to get a rough idea about how many FR's are to be fixed, drop a message in this list. cheers itman Hello, I'm also interested. Mathias ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-Fix in switzerland
On Tue, 13 Oct 2009 17:00:48 +0200 Michal Brzozowski ruso...@poczta.fm (MB) wrote: Sending to Czech Republic would be definitely easier as there are no customs involved (I'm in Poland). Does the person you've got provide any guarantees for the rework? Would you guys test my FR to see if the recamping is gone before you send it back? Michal, we have given one FR to the tech guy today, with the hope he will have it ready before Friday. the biggest question is how reliably is he gonna be able to open up the can... the fix is then quite trivial... closing up also. i am hoping to drive over on Friday to have my FR #1024_fixed too, the weekend should be survived on one batter charge only :) (well, i guess not for me, as i have only one really weak cell tower around...) anyhow, i'll keep you up to date, Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 1024#
Hi, I recently got my phone buzz and 1024 fixed in Delhi. (Thanks Zoheb and Rakshat). But, I now have a different problem. My phone refuses to register to the cell 3 out of 4 times with the following errors :- 2009.10.15 07:29:37.114 frameworkd.resource INFO setting resource status for GSM from enabled to disabling 2009.10.15 07:29:38.235 frameworkd.resource INFO setting resource status for GSM from disabling to disabled 2009.10.15 07:29:38.395 ophoned.protocol INFO removing protocol GSM 2009.10.15 07:29:43.927 frameworkd.resource INFO setting resource status for GSM from disabled to enabling 2009.10.15 07:29:43.948 ogsmd.channelINFO CallChannel via unknown: Creating channel with timeout = 3600 seconds 2009.10.15 07:29:43.996 ogsmd.channelINFO UnsolicitedResponseChannel via unknown: Creating channel with timeout = 300 seconds 2009.10.15 07:29:44.99 ogsmd.channelINFO MiscChannel via unknown: Creating channel with timeout = 300 seconds 2009.10.15 07:29:44.149 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:29:57.870 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:29:57.880 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:11.55 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:30:11.65 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:24.375 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:30:24.502 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:37.700 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:30:37.710 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:50.900 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:30:50.910 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:04.100 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:31:04.109 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:17.300 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:31:17.310 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:30.485 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:31:30.495 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:43.675 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:31:43.805 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:56.985 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:31:56.997 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:32:10.355 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:32:10.365 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:32:23.540 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:32:23.550 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' and so on Any ideas what the problem could be? What do MISC, UNSOL and CALL mean? Thanks -- View this message in context: http://n2.nabble.com/1024-tp3780520p3826812.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
GSM errors after 1024 fix
Hi, Thought I'll start a new thread. I got the buzz and 1024 fixes done at Delhi yesterday (thanks Zoheb and Rakshat). But after a few restarts I'm facing this new problem - my modem doesn't register and I get errors like :- 2009.10.15 07:29:37.114 frameworkd.resource INFO setting resource status for GSM from enabled to disabling 2009.10.15 07:29:38.235 frameworkd.resource INFO setting resource status for GSM from disabling to disabled 2009.10.15 07:29:38.395 ophoned.protocol INFO removing protocol GSM 2009.10.15 07:29:43.927 frameworkd.resource INFO setting resource status for GSM from disabled to enabling 2009.10.15 07:29:43.948 ogsmd.channelINFO CallChannel via unknown: Creating channel with timeout = 3600 seconds 2009.10.15 07:29:43.996 ogsmd.channelINFO UnsolicitedResponseChannel via unknown: Creating channel with timeout = 300 seconds 2009.10.15 07:29:44.99 ogsmd.channelINFO MiscChannel via unknown: Creating channel with timeout = 300 seconds 2009.10.15 07:29:44.149 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:29:57.870 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:29:57.880 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:11.55 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:30:11.65 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:24.375 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:30:24.502 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:37.700 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:30:37.710 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:50.900 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:30:50.910 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:04.100 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:31:04.109 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:17.300 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:31:17.310 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:30.485 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:31:30.495 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:43.675 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:31:43.805 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:56.985 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:31:56.997 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:32:10.355 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:32:10.365 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:32:23.540 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:32:23.550 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' and so on Any ideas what the problem could be? What do MISC, UNSOL and CALL mean? Thanks. -- View this message in context: http://n2.nabble.com/GSM-errors-after-1024-fix-tp3827146p3827146.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: GSM errors after 1024 fix
Did u manage to register at all after the fix? Or the error started later? On 10/15/09, c_c cchan...@yahoo.com wrote: Hi, Thought I'll start a new thread. I got the buzz and 1024 fixes done at Delhi yesterday (thanks Zoheb and Rakshat). But after a few restarts I'm facing this new problem - my modem doesn't register and I get errors like :- 2009.10.15 07:29:37.114 frameworkd.resource INFO setting resource status for GSM from enabled to disabling 2009.10.15 07:29:38.235 frameworkd.resource INFO setting resource status for GSM from disabling to disabled 2009.10.15 07:29:38.395 ophoned.protocol INFO removing protocol GSM 2009.10.15 07:29:43.927 frameworkd.resource INFO setting resource status for GSM from disabled to enabling 2009.10.15 07:29:43.948 ogsmd.channelINFO CallChannel via unknown: Creating channel with timeout = 3600 seconds 2009.10.15 07:29:43.996 ogsmd.channelINFO UnsolicitedResponseChannel via unknown: Creating channel with timeout = 300 seconds 2009.10.15 07:29:44.99 ogsmd.channelINFO MiscChannel via unknown: Creating channel with timeout = 300 seconds 2009.10.15 07:29:44.149 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:29:57.870 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:29:57.880 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:11.55 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:30:11.65 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:24.375 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:30:24.502 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:37.700 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:30:37.710 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:30:50.900 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:30:50.910 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:04.100 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:31:04.109 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:17.300 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:31:17.310 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:30.485 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:31:30.495 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:43.675 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:31:43.805 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:31:56.985 ogsmd.modem.abstract ERRORcould not open channel MISC, retrying in 2 seconds 2009.10.15 07:31:56.997 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:32:10.355 ogsmd.modem.abstract ERRORcould not open channel UNSOL, retrying in 2 seconds 2009.10.15 07:32:10.365 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' 2009.10.15 07:32:23.540 ogsmd.modem.abstract ERRORcould not open channel CALL, retrying in 2 seconds 2009.10.15 07:32:23.550 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' and so on Any ideas what the problem could be? What do MISC, UNSOL and CALL mean? Thanks. -- View this message in context: http://n2.nabble.com/GSM-errors-after-1024-fix-tp3827146p3827146.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 -- -- Please use Firefox as your web browser. Its protects you from spyware and is also a very feature rich browser. www.firefox.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
