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
jO
d 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 bug
#1024 and is interested in getting that re
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
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
m 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:
>
>>
>
>> 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-bu
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...
Regard
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. Thi
Alishams Hassam 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).
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 ?
> --
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 wrote:
> On Wedn
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 &
On Wed, 28 Apr 2010 10:31:30 +0200
"Gand'" (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 alrea
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 wrote:
>
> another cause maybe:
&g
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 fixe
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
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
Hi Niels,
Already did it (1024 bug fix and parameter modified)
Regards,
Yann
- Mail Original -
De: "Niels Heyvaert"
À: community@lists.openmoko.org
Envoyé: Mercredi 14 Avril 2010 10:11:00 GMT +01:00 Amsterdam / Berlin / Berne /
Rome / Stockholm / Vienne
Objet: RE: [QtMoko
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 m
As said before, by modifying parameter 'Active' from' never' to 'always'
and then reboot the phone
Yann
> Yann SLADEK 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.c
LADEK <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, t
On 13 April 2010 22:18, Yann SLADEK 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
Yann SLADEK 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://li
On Tue, Apr 13, 2010 at 10:18 PM, Yann SLADEK 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 (
(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 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/frame
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
Am Samstag 06 Februar 2010 17:01:26 schrieb Dr. H. Nikolaus Schaller:
> Am 06.02.2010 um 16:53 schrieb Christ van Willegen:
> > Hello Nikolaus,
> >
> > On Sat, Feb 6, 2010 at 3:38 PM, Dr. H. Nikolaus Schaller
> >
> > wrote:
> >> there is now a Bu
Am 06.02.2010 um 16:53 schrieb Christ van Willegen:
> Hello Nikolaus,
>
> On Sat, Feb 6, 2010 at 3:38 PM, Dr. H. Nikolaus Schaller
> wrote:
>> there is now a Buzz-Fix and #1024 fix opportunity at FOSDEM.
>
> Great news!
>
> Will this nice guy also be there tomorro
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 t
Hello Nikolaus,
On Sat, Feb 6, 2010 at 3:38 PM, Dr. H. Nikolaus Schaller
wrote:
> there is now a Buzz-Fix and #1024 fix opportunity at FOSDEM.
Great news!
Will this nice guy also be there tomorrow?
See you tomorrow!
Christ van Wille
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
hi,
thank you!
that info worked for me, it seems that i did ok the fix!
chris
--
View this message in context:
http://n2.nabble.com/how-can-I-check-the-1024-bug-fix-tp4496461p4500479.html
Sent from the Openmoko Community mailing list archive at Nabble.com
On Mon, Feb 01, 2010 at 12:45:21PM -0800, xChris wrote:
>
> this..
Here is also some description how to check that
http://www.handheld-linux.com/wiki.php?page=1024-Rework
--
uin:136542059jid:martin.ja...@gmail.com
Jansa Martin sip:jama...@voip.wengo.fr
ice" )
gobject.threads_init()
dbus.glib.init_threads()
main_loop = gobject.MainLoop()
main_loop.run()
--
thx
chris
--
View this message in context:
http://n2.nabble.com/how-can-I-check-the-1024-bug-fix-tp4496461p4496786.html
Sent from the Openmoko Community mailing list archive at
xChris writes:
> Anyway, now I am running the KaZeR's script but there is no output, is it
> 'normal' ?
> I could see some output before the fix..
Where's the script?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmo
Hi.
I managed to do the fix of the 1024 bug (not too difficult, only the removal
of the GSM shield was a bit... aarghhh)
Thanx guys for the info on how to do this (esp the the web page :
http://neofundas.blogspot.com/)
Anyway, now I am running the KaZeR's script but there is no output,
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 kin
OK thanks i'll try tomorrow ;-)
On 12/4/09, arne anka 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
> 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
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 r
> 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 wor
efor 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.
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
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.
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
sati
...
>
> 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
toms 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
> 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
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
Michael Smith a écrit :
> On Wed, 28 Oct 2009 13:04:54 +0100
> Davide Scaini 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
>&g
On Wed, 28 Oct 2009 13:04:54 +0100
Davide Scaini 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
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
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" ---
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 attractiv
dication 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 s
d
>> 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 anothe
On Fri, Oct 23, 2009 at 1:07 PM, Dr. H. Nikolaus Schaller
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
if i buy the rework, i would by an invisible shield as well.
would you be able to apply that shield to the lcd since the cover is off
anyway?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/co
On Fri, 23 Oct 2009 13:06:07 +0200
Michael 'Mickey' Lauer (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
>
> 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
x27;t know either
Nikolaus
Am 23.10.2009 um 12:39 schrieb Yorick Moko:
> On 10/22/09, 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
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
On 10/22/09, 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
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
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/
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 German
|-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
On Thu, Oct 22, 2009 at 1:16 AM, Dr. H. Nikolaus Schaller
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
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.openm
-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 th
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
>&
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 g
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
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 ma
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:
_
ges?
--
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
On Mon, 19 Oct 2009 17:15:18 +0200
Michael 'Mickey' Lauer (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 (DF) wrote:
>>
>> >actually i was vague/misleading in what i wrote. what i would like
>> >to see is for the end
Am Montag, den 19.10.2009, 12:46 +0200 schrieb Petr Vanek:
> On Mon, 19 Oct 2009 01:50:51 -0400
> David Ford (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 messag
On Mon, 19 Oct 2009 01:50:51 -0400
David Ford (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 th
leep_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
On Mon, 19 Oct 2009 00:32:28 -0400
David Ford (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 m
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,
>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.c
>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
: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. Fram
On 10/18/09, Petr Vanek 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
>>>...
>&
>> 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 :-(
>
>
>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
>>>> 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 sc
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
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
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
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.
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 he
Le Fri, 16 Oct 2009 11:11:47 +0200,
"DRSp." 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)
>
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
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 Comm
> 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 a
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 tha
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-tp3827146p38275
1 - 100 of 230 matches
Mail list logo