Bug #1024 (oscillating re-camping), a possible solution.

[Dieter Spaar]

Hello,

We have now tested a few phones and it seems that
increasing a capacitor solves the re-camping bug.

The problem most certainly comes from a sub-optimal
PCB layout where a voltage regulator feedback trace
is not close enough to the consumer so that the
length of the trace from the regulator to the consumer
has a considerable influence. Additionally there is
a 0R resistor in this trace which might not be exactly
zero all the time (it might also depend on how good
the soldering is).

Increasing the capacitor which buffers this power supply
line seems to help.

We don't know exactly what happens inside the Calypso but
it could be that the power drop is too large when the
Calypso wakes up from "Deep Sleep" (which means it
draws more current again) and this causes the next PCH
reception to fail (for whatever reason).

The appended picture shows this capacitor (its C1009,
a 10 uF ceramic capacitor), you have to remove the GSM
modem shielding to find it.

This picture shows one possible solution to increase this
capacitor, there is a second 10 uF capacitor connected. The
location of this second capacitor is intentionally that far
away because there is no other place where you have enough
room to place the capacitor without risking a shortcut with
components below on the PCB and not exceeding the height
so that the shielding still fits. You should of course place
some insulation on the shielding to avoid a shortcut with
the second capacitor.

The other solution is to remove C1009 and replace it
with a 22 uF capacitor. Daniel Willmann has done this
successfully with a few phones.

This is it for now, maybe our hardware experts will
add some more comments.

Best regards,
  Dieter


_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Dima Kogan]

I just performed this fix and so far the recamping is successfully
squashed. I'm not seeing any recamping (was fairly common before the
fix). Instead of placing the second capacitor away from the first and
using a wire to connect the two, I placed it directly adjacent to the
first, using some electrical tape to isolate it from the components
directly beneath.

Thank you, Dieter.

Dima

On Mon, 25 May 2009 20:40:02 +0200
Dieter Spaar <[hidden email]> wrote:

> Hello,
>
> We have now tested a few phones and it seems that
> increasing a capacitor solves the re-camping bug.
>
> The problem most certainly comes from a sub-optimal
> PCB layout where a voltage regulator feedback trace
> is not close enough to the consumer so that the
> length of the trace from the regulator to the consumer
> has a considerable influence. Additionally there is
> a 0R resistor in this trace which might not be exactly
> zero all the time (it might also depend on how good
> the soldering is).
>
> Increasing the capacitor which buffers this power supply
> line seems to help.
>
> We don't know exactly what happens inside the Calypso but
> it could be that the power drop is too large when the
> Calypso wakes up from "Deep Sleep" (which means it
> draws more current again) and this causes the next PCH
> reception to fail (for whatever reason).
>
> The appended picture shows this capacitor (its C1009,
> a 10 uF ceramic capacitor), you have to remove the GSM
> modem shielding to find it.
>
> This picture shows one possible solution to increase this
> capacitor, there is a second 10 uF capacitor connected. The
> location of this second capacitor is intentionally that far
> away because there is no other place where you have enough
> room to place the capacitor without risking a shortcut with
> components below on the PCB and not exceeding the height
> so that the shielding still fits. You should of course place
> some insulation on the shielding to avoid a shortcut with
> the second capacitor.
>
> The other solution is to remove C1009 and replace it
> with a 22 uF capacitor. Daniel Willmann has done this
> successfully with a few phones.
>
> This is it for now, maybe our hardware experts will
> add some more comments.
>
> Best regards,
>   Dieter

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Wolfgang Spraul]

Some javascript/style in this post has been disabled (why?)

Dima,
wow this is excellent news!
How long did it take you to do this fix? How hard was it, how about likelihood that the phone will get damaged in the process?
Maybe we should publish a proper PDF SOP, wich some neat pictures and such?
Or roll it into the buzz-rework SOP?

More reports on this would be very welcome...
Thanks everybody!
Wolfgang

Dima Kogan wrote:

I just performed this fix and so far the recamping is successfully
squashed. I'm not seeing any recamping (was fairly common before the
fix). Instead of placing the second capacitor away from the first and
using a wire to connect the two, I placed it directly adjacent to the
first, using some electrical tape to isolate it from the components
directly beneath.

Thank you, Dieter.

Dima

On Mon, 25 May 2009 20:40:02 +0200
Dieter Spaar [hidden email] wrote:

  

Hello,

We have now tested a few phones and it seems that
increasing a capacitor solves the re-camping bug.

The problem most certainly comes from a sub-optimal
PCB layout where a voltage regulator feedback trace
is not close enough to the consumer so that the
length of the trace from the regulator to the consumer
has a considerable influence. Additionally there is
a 0R resistor in this trace which might not be exactly
zero all the time (it might also depend on how good
the soldering is).

Increasing the capacitor which buffers this power supply
line seems to help.

We don't know exactly what happens inside the Calypso but
it could be that the power drop is too large when the
Calypso wakes up from "Deep Sleep" (which means it
draws more current again) and this causes the next PCH
reception to fail (for whatever reason).

The appended picture shows this capacitor (its C1009,
a 10 uF ceramic capacitor), you have to remove the GSM
modem shielding to find it.

This picture shows one possible solution to increase this
capacitor, there is a second 10 uF capacitor connected. The
location of this second capacitor is intentionally that far
away because there is no other place where you have enough
room to place the capacitor without risking a shortcut with
components below on the PCB and not exceeding the height
so that the shielding still fits. You should of course place
some insulation on the shielding to avoid a shortcut with
the second capacitor.

The other solution is to remove C1009 and replace it
with a 22 uF capacitor. Daniel Willmann has done this
successfully with a few phones.

This is it for now, maybe our hardware experts will
add some more comments.

Best regards,
  Dieter
    

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
  

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Dieter Spaar]

Hello Dima,

Dima Kogan wrote:
> I just performed this fix and so far the recamping is successfully
> squashed. I'm not seeing any recamping (was fairly common before the
> fix). Instead of placing the second capacitor away from the first and
> using a wire to connect the two, I placed it directly adjacent to the
> first, using some electrical tape to isolate it from the components
> directly beneath.
>  

Great to hear that it worked and that you found an even simpler way for
the fix. And thanks for this feedback, I really appreciate it.

Best regards,
  Dieter

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Davide]

On Tuesday 26 May 2009 11:17:24 Dima Kogan wrote:
> I just performed this fix and so far the recamping is successfully
> squashed. I'm not seeing any recamping (was fairly common before the
> fix). Instead of placing the second capacitor away from the first and
> using a wire to connect the two, I placed it directly adjacent to the
> first, using some electrical tape to isolate it from the components
> directly beneath.

Wow! These are really good news!

Dima: Could you please make any tests on battery life with and without
calypso_deep_sleep?

Wolfgang: It would be GREAT if we could get also this fix on the buzz fix
party. Any hope on this? :)

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Dieter Spaar]

Hello,

David Garabana Barro wrote:
> Dima: Could you please make any tests on battery life with and without
> calypso_deep_sleep?
>  

Just a note: The time how long the GSM modem can go into "Deep Sleep"
is mainly determined by a parameter of the cell. Its the BS_PA_MFRMS,
parameter, range 2 to 9, which translates to about 471.9 ms to 2122.2 ms
of time between receiving the PCH. The possible "Deep Sleep" time is
shorter because of the overhead for waking up, receiving the burst and so
on. Please keep this in mind when doing a test, it depends on the cell too.
You can query this cell parameter with "AT%EM=2,4", its the first number
of the result.

Best regards,
  Dieter

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Daniel Willmann-2]

On Tue, 26 May 2009 12:28:55 +0200
David Garabana Barro <[hidden email]> wrote:

> On Tuesday 26 May 2009 11:17:24 Dima Kogan wrote:
> > I just performed this fix and so far the recamping is successfully
> > squashed. I'm not seeing any recamping (was fairly common before the
> > fix). Instead of placing the second capacitor away from the first
> > and using a wire to connect the two, I placed it directly adjacent
> > to the first, using some electrical tape to isolate it from the
> > components directly beneath.
>
> Wow! These are really good news!
>
> Dima: Could you please make any tests on battery life with and
> without calypso_deep_sleep?
>
> Wolfgang: It would be GREAT if we could get also this fix on the buzz
> fix party. Any hope on this? :)

I have been doing this unofficially for some people to help with
testing that solution. So far everything seems to indicate that it at
least cures the symptoms. :-)

As soon as an agreement is reached with OM I can do that officially at
buzzfix parties or mail in.


Revgards,
Daniel Willmann


_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Werner Almesberger]

Dieter Spaar wrote:
> Increasing the capacitor which buffers this power supply
> line seems to help.

Dieter, I think we all owe you a big applause for finding a solution
for this bug. #1024 is as old as Openmoko or even predates it. Many
people have tried their luck at solving this problem and it has been
overlooked, denied, ignored, given up on, and worked around, but only
you had the perseverance and skills to come up with a plausible
explanation and a fix.

Let's also not forget all the others who have contributed towards
killing this beast, particularly Mickey, Mike, Joerg, Daniel,
Wolfgang, and Steve.

Thanks and congratulations !

- Werner

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Werner Almesberger]

I wrote:
> Let's also not forget all the others who have contributed towards
> killing this beast, [...]

And Tony !

- Werner (needs new memory)

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Dieter Spaar]

Hello Werner,

Werner Almesberger wrote:
> Dieter, I think we all owe you a big applause for finding a solution
> for this bug. #1024 is as old as Openmoko or even predates it. Many
> people have tried their luck at solving this problem and it has been
> overlooked, denied, ignored, given up on, and worked around, but only
> you had the perseverance and skills to come up with a plausible
> explanation and a fix.
>  

Thank you very much. I think the fix is OK, if the explanation is really
the truth can
only be determined by a modified layout and checking if it shows the
same problem.

> Let's also not forget all the others who have contributed towards
> killing this beast, particularly Mickey, Mike, Joerg, Daniel,
> Wolfgang, and Steve.
>  
Yes, of course, thank to all who contributed and spent a lot of time on
it. And besides
Tony  (you mentioned in your  second mail) I would also like to mention
Dima and Al
and don't forget to add yourself to the list :-).

Best regards,
  Dieter


_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Nils Faerber]

Dieter Spaar schrieb:
> Hello,
Hi!

> We have now tested a few phones and it seems that
> increasing a capacitor solves the re-camping bug.

First of all: Congratulations for finding a solution!
Many thanks!

[...]
> The other solution is to remove C1009 and replace it
> with a 22 uF capacitor. Daniel Willmann has done this
> successfully with a few phones.

So this is really 22µF, not 22nF?
This a quite big capacity.
And @ which voltage? If I look at Farnell's offerings they have
different types in 1V steps, i.e. e.g. 3V and 4V. And finally which form
factor is this? Is it 0805 or 0603? Judging from the picture I would
guess 0805, right? I have not opened my GTA yet and would only do so
after the parts arrived so I only have to do it once ;)

And as a very last question: Does this also apply to GTA01? And if yes,
could someone point out which capacitor it is there, ideally with a PCB
position (either photo or placement graph).

Many many thanks again!
This brings the GTA phones one step closer in usability.

PS: We have a small workshop here - so once the details are clear I can
offer to do the rework also for other GTA owners, maybe also along with
the buzz-fix if needed (but without warrenty :)

> Best regards,
>  Dieter
Cheers
  nils faerber

--
kernel concepts GbR        Tel: [phone]
Sieghuetter Hauptweg 48    Fax: [phone]
D-57072 Siegen             Mob: [phone]
http://www.kernelconcepts.de


_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Michael 'Mickey' Lauer-2]

Just an additional heads-up. Daniel reworked my device on the hardware
workshop which was part of the first FSOSHR conference last weekend in
the LinuxHotel.

Since then I exposed my FreeRunner to the tough RF conditions in my
office-basement here in Frankfurt/Main and I'm glad to announce that I
had not a single recamping since then.

Cheers,

Mickey.



_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Daniel Willmann-2]

Hi,

On Thu, 28 May 2009 14:18:46 +0200
Michael 'Mickey' Lauer <[hidden email]> wrote:

> Since then I exposed my FreeRunner to the tough RF conditions in my
> office-basement here in Frankfurt/Main and I'm glad to announce that I
> had not a single recamping since then.

Great! How did fso-abyss and framework treat you with regard to the
channel timeout?

Regards,
Daniel Willmann


_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Daniel Willmann-2]

Hi,

On Thu, 28 May 2009 12:48:59 +0200
Nils Faerber <[hidden email]> wrote:

> Dieter Spaar schrieb:
> > The other solution is to remove C1009 and replace it
> > with a 22 uF capacitor. Daniel Willmann has done this
> > successfully with a few phones.
>
> So this is really 22µF, not 22nF?
> This a quite big capacity.

that is correct.
22µF 0805, 6.3V is what I use. 4V should work as well I guess.
http://de.farnell.com/kemet/c0805c226m9pac7800/kondensator-0805-22uf-x5r/dp/1108326
should work fine I guess (haven't tried it yet).

> And as a very last question: Does this also apply to GTA01? And if
> yes, could someone point out which capacitor it is there, ideally
> with a PCB position (either photo or placement graph).

It's also C1009 there and also 10µF. I guess it's generally safe to
assume that schematics/layout of the GSM part haven't changed much
between these two versions.


Regards,
Daniel Willmann


_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Nils Faerber]

Perfect, many thanks!

Daniel Willmann schrieb:

> Hi,
>
> On Thu, 28 May 2009 12:48:59 +0200
> Nils Faerber <[hidden email]> wrote:
>
>> Dieter Spaar schrieb:
>>> The other solution is to remove C1009 and replace it
>>> with a 22 uF capacitor. Daniel Willmann has done this
>>> successfully with a few phones.
>> So this is really 22µF, not 22nF?
>> This a quite big capacity.
>
> that is correct.
> 22µF 0805, 6.3V is what I use. 4V should work as well I guess.
> http://de.farnell.com/kemet/c0805c226m9pac7800/kondensator-0805-22uf-x5r/dp/1108326
> should work fine I guess (haven't tried it yet).
>
>> And as a very last question: Does this also apply to GTA01? And if
>> yes, could someone point out which capacitor it is there, ideally
>> with a PCB position (either photo or placement graph).
>
> It's also C1009 there and also 10µF. I guess it's generally safe to
> assume that schematics/layout of the GSM part haven't changed much
> between these two versions.
>
>
> Regards,
> Daniel Willmann

Cheers
  nils faerber

--
kernel concepts GbR        Tel: [phone]
Sieghuetter Hauptweg 48    Fax: [phone]
D-57072 Siegen             Mob: [phone]
http://www.kernelconcepts.de


_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Mike Westerhof (mwester)]

Michael 'Mickey' Lauer wrote:
> Just an additional heads-up. Daniel reworked my device on the hardware
> workshop which was part of the first FSOSHR conference last weekend in
> the LinuxHotel.
>
> Since then I exposed my FreeRunner to the tough RF conditions in my
> office-basement here in Frankfurt/Main and I'm glad to announce that I
> had not a single recamping since then.

I'll add my thanks to the team that has finally cracked this problem as
well.  Well done!

I'm rather familiar with this problem, having spent a lot of time on the
software workarounds.  I'm pleased to report that with the addition of a
10uF cap, my GTA02 has not reported a single recamping event in 20 days.
 Previously, it recamped consistently within 45 seconds of entering
deep-sleep.

Thanks folks!  :)

Mike (mwester)

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Joerg Reisenweber]

Just to mention it once again, and to stop a possible stampede:
AT%sleep=2 (sw-fix[1]) has fixed recamping reliably for 100% of affected
devices. Not all devices suffer from #1024, actually it seems it's only a
small percentage. FSO is capable of switching to AT%sleep=2 even
automatically[1].
Last not least: probably a better battery management will have more positive
effects on standby time than fixing #1024 in hw and using AT%sleep=4 all the
time. First raw estimations seem to suggest there's an increase in standby
time from maybe 60h with sleep2 to 75h with sleep4. If your standby time is
shorter than these figures then even percentage of difference gets *smaller*
(e.g. like 20h vs 21h = 5%, instead of 60/75 = 25%), due to savings from
sleep4 becoming negligible compared to higher suspend consumption of whole
system.

cheers
jOERG




[1]http://git.freesmartphone.org/?p=framework.git;a=blob;f=conf/example/frameworkd.conf
 
      [framework.git] / conf / example / frameworkd.conf
101 # if you have a ti_calypso, you can choose the deep sleep mode. Valid
        values are: never, adaptive (default), always
102 ti_calypso_deep_sleep = adaptive

find this file in /etc/frameworkd.conf on your Neo.
If you're concerned about #1024 and the short connectivity loss that might
happen until frameworkd senses it has to switch to sleep=2, then change to
  ti_calypso_deep_sleep = never
which sets calypso to AT%SEEP=2. "always" is eqiv to AT%SEEP=4. "adaptive"
means frameworkd is sensing #1024 recamping and switches from sleep4 to
sleep2 automatically. This sensing might take a minute or two.


_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Steve Mosher]

thx joerg


Joerg Reisenweber wrote:

> Just to mention it once again, and to stop a possible stampede:
> AT%sleep=2 (sw-fix[1]) has fixed recamping reliably for 100% of affected
> devices. Not all devices suffer from #1024, actually it seems it's only a
> small percentage. FSO is capable of switching to AT%sleep=2 even
> automatically[1].
> Last not least: probably a better battery management will have more positive
> effects on standby time than fixing #1024 in hw and using AT%sleep=4 all the
> time. First raw estimations seem to suggest there's an increase in standby
> time from maybe 60h with sleep2 to 75h with sleep4. If your standby time is
> shorter than these figures then even percentage of difference gets *smaller*
> (e.g. like 20h vs 21h = 5%, instead of 60/75 = 25%), due to savings from
> sleep4 becoming negligible compared to higher suspend consumption of whole
> system.
>
> cheers
> jOERG
>
>
>
>
> [1]http://git.freesmartphone.org/?p=framework.git;a=blob;f=conf/example/frameworkd.conf
>  
>       [framework.git] / conf / example / frameworkd.conf
> 101 # if you have a ti_calypso, you can choose the deep sleep mode. Valid
> values are: never, adaptive (default), always
> 102 ti_calypso_deep_sleep = adaptive
>
> find this file in /etc/frameworkd.conf on your Neo.
> If you're concerned about #1024 and the short connectivity loss that might
> happen until frameworkd senses it has to switch to sleep=2, then change to
>   ti_calypso_deep_sleep = never
> which sets calypso to AT%SEEP=2. "always" is eqiv to AT%SEEP=4. "adaptive"
> means frameworkd is sensing #1024 recamping and switches from sleep4 to
> sleep2 automatically. This sensing might take a minute or two.
>  

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Al Johnson]

On Monday 25 May 2009, Dieter Spaar wrote:
> We have now tested a few phones and it seems that
> increasing a capacitor solves the re-camping bug.

What a nice surprise to have after a week away :-) Many thanks to Dieter and
everyone else involved.

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Daniel Willmann-2]

Hi,

On Fri, 29 May 2009 22:58:53 +0200
Joerg Reisenweber <[hidden email]> wrote:

> Last not least: probably a better battery management will have more
> positive effects on standby time than fixing #1024 in hw and using
> AT%sleep=4 all the time. First raw estimations seem to suggest
> there's an increase in standby time from maybe 60h with sleep2 to 75h
> with sleep4. If your standby time is shorter than these figures then
> even percentage of difference gets *smaller* (e.g. like 20h vs 21h =
> 5%, instead of 60/75 = 25%), due to savings from sleep4 becoming
> negligible compared to higher suspend consumption of whole system.

I ran a battery consumption test on my #1024 fixed freerunner, the
results of which can be seen here:
http://totalueberwachung.de/blog/2009/06/03/freerunner-deep-sleep-standby-time

I got close to 6 days worth of standby time (143h) which I found rather
impressive. The phone was not used at all for calls so the value
represents an upper limit, but I checked that the GSM modem was still
operational by calling the device at the end. I'm currently repeating
the test once more and will post an update once it's done, but it seems
we'll be in the 130-140h region again.

Regards,
Daniel Willmann


_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware