from:"Joerg Reisenweber"

Am Do  28. August 2008 schrieb Cesar Eduardo Barros:
 Andy Green escreveu:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Somebody in the thread at some point said:
  | In a message from Ben Dooks on linux-arm-kernel about cpufreq, he said:
  |
  |- My patches have code to use hardware flow control to pause the
  |serial ports during frequency transitions, so as to not confuse the
  |GTA01 GSM modem (or Openmoko's gsmd).
  |  
  |   That is useful for designs that forgot to provide a stable UCLK to
  |   provide UART baud clocks... all of the ones that I've had a direct
  |   hand in working on feed back or feed in an external known (and 
stable)
  |   clock.
  |
  | It might be worth considering this on future designs (looking at the
  | schematics, GTA01 uses the pin for something else, while GTA02 doesn't
  | connect the pin at all).
  
  It's a good point, it would help the UART continuity during clock
  change.  But it means adding an oscillator somewhere?  There's a PLL
  from the Wolfson we could maybe use.
 
 A possible trick would be to route the output of the USB PLL to a pin, 
 and have a trace linking that pin to the UART external clock. The USB 
 PLL isn't affected when the main PLL changes (or at least shouldn't be).
 
 For the GTA02, for instance, that would mean a trace between 
 UEXTCLK/GPH8 and CLKOUT1/GPH10 (which would also allow several other 
 options besided the USB PLL). Both pins are free on the GTA02, but I 
 don't know if routing that trace would be easy (especially considering 
 the trace would be carrying a 48MHz signal).
 
 For a USB clock of 48MHz, that would give us a UBRDIV of 25 for 115200, 
 which feeding the formula in the reverse results in a baud rate of 
 115385, an error of 0.16% (unless I made a mistake on the calculations). 
 This is less than the about 1.87% where things start having problems.
 
 Of course, even with all that it would still be a good idea to pause 
 the flow control during the PLL lock time to avoid a buffer overrun, but 
 the AFC might be able to do it automatically for us. The problem avoided 
 by using a stable clock is mainly the frequency changing (or the clock 
 stopping) in the middle of a byte.

Sounds very attractive, and stopping clock in midst of an inbound byte is an 
absolute NoGo for e.g. GSM-TTY. To avoid this we had to assert flow control 
to stop, and then delay for the maximum time to take effect of this. This 
delay slows down clock rate changes considerably.
Probably routing of a 48MHz signal from one pin of CPU to another is no issue 
(if we care for decent shielding of this trace ;-). However we can't do this 
for devices prior to GTA02A8 (A7 maybe), for obvious reasons. So sw would 
have to check for hw-revision (once again ;-).

Should we try to set up a ECN demanding future (GTA02) devices to have this? 
Andy? Werner? I consider engineering risk very low, as we always may fall 
back to current scheme.

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: UCLK

Am Do  28. August 2008 schrieb Werner Almesberger:
 Joerg Reisenweber wrote:
  Should we try to set up a ECN demanding future (GTA02) devices to have 
this? 
  Andy? Werner? I consider engineering risk very low, as we always may fall 
  back to current scheme.
 
 Sounds good and safe to me as well. One problem is that UCLK/GPH8 is
 currently used in GTA03, so we'd have to find a way to free this if
 we don't want to regress.

one more good reason to do it *now*, as we easily can reorder GPIO for GTA03 
in this stage of development.
So I guess I'll set up a ECN for GTA02 *and* GTA03.
Andy, any comments?

/jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: USB-OVP

Am Do  28. August 2008 schrieb Andy Green:
 Somebody in the thread at some point said:
 
 | Charger Overshoot Voltage VCHGR_OVRSHT 6.0 V max.
 | -
 |
 | Though we couldn't even attach a USB-charger compliant to this spec,
 as it has
 | to be equipped with micro-USB plug, we should expect to see voltages on
 | USB-receptacle of up to 6.0V AT LEAST.
 
 Why?  Our charger doesn't follow that spec that mentions 6.0V.
 
 | I think it's a strong argument for additional OVP extending our actual
 | abs.max.rating of 5.5V to limits safely beyond 6.0V, like we are actually
 | about to do for GTA03.
 
 Regulator and cap in the charger should mitigate this.  Why don't we
 measure our actual charger performance in this case, shouldn't be too hard.

For one simple reason: USB-charging was meant to work with *any* USB-charger 
(otherwise we would have used ID-pin for VDD of charger ;-) and Neo wouldn't 
take any power from USB-VBUS, thus no issue with OVP), and for sure we don't 
want to restrict customers to usage of OM-wallwart-powersupply only. We 
wouldn't even get away with this, legally. As long as our device has a 
USB-receptacle, it has to cope with insertion of what a customer can 
reasonably assume should work when attached to it.

Then we also got the *wide* field of externally powered hubs. Ever had a look 
at the way those are providing power to downstream-connectors? And at the 
power-supplies that are (or are not!) shipped with these hubs.
Dear customer! There are a plethora of powered USB-hubs out there. We 
strongly recommend NOT to attach Neo to any of those, as we didn't care to 
protect the device against voltages that may be found on a lot of the cheaper 
ones you might incidentally use. Please connect Neo to the original charger 
or certified good hosts only! :-(
Do we really need more reasons to care about that issue?

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: UCLK

Am Do  28. August 2008 schrieb Werner Almesberger:
 Joerg Reisenweber wrote:
  Ah, and btw: does anybody have a decent set of bookmarks/pointers/quotes 
to 
  S3C2442 datasheet sections needed to facilitate my duty to validate this 
ECN? 
 
 I think we need a more specific question :-)
 
 I.e., it's a connection between pads that are currently unconnected,
 they both can be disabled if it turns our they cannot be used, and
 the only thing between them is another pad that is usually disabled,
 So what additional validation do you need ?
 
 If sending UCLK to from CLKOUT1 to UEXTCLK should end up exciting
 CLKOUT0 and causing some obscure interference, we probably won't
 find out in any theoretical study anyway.

I thought about much more basic things like check if it's the right pin 
name, check if logic levels, fan in and fan out match, check if the whole 
idea is actually feasible etc.
For this I have to scrutinize the corresponding sections in CPU datasheet, so 
I understand what I'm asking for and what it should work like, instead of 
just forwarding a bake recipe from ML. So some pointer would be welcome ;-)
Not eager to search the whole manual for UEXTCLK

/jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: USB-OVP

2008-08-29 Thread Joerg Reisenweber

Am Fr  29. August 2008 schrieb Andy Green:
 Somebody in the thread at some point said:
 | Joerg Reisenweber wrote:
 | Do we really need more reasons to care about that issue?
 |
 | How about Postel's law ?
 |
 | http://en.wikipedia.org/wiki/Robustness_Principle
 |
 | Sounds like a good enough rule to follow at any interface, not just
 | software interfaces.
 
 ''Be conservative in what you do, be liberal in what you accept from
 others'' is a nice general principle.
 
 But then where does one stop, accepting mains power directly, automotive
 12V, 12V charger connection, broken chargers...  
I gave some sort of spec in start of this thread, to give you an idea where 
*not* to stop, and this is 5.5V abs.max.rating of PMU. But seems you are 
considering to better not start at all on improving this situation, as *you* 
seem to fear *you* don't see a point to stop at. Whereas we started to think 
about it and when we see we landed at 25V OVP with our solution at 
(virtually) no additional costs, *we* all knew we did it and it's much better 
now.

 it is a guiding 
 principle to be taken into account at specification time.  Every new
 thing we accept to support has costs.
False. Obviously, evidentally *not*, as you notice yourself in last line of 
your post.

 
 What I like though is the Be conservative in what you do part of it.
 Because we have not seen failures in the field from GTA02 arrangements,
False. You don't stop to allege this, but actually there *are* some devices 
with obviously broken PMU... --

 I am having a hard time accepting we need to change anything from proven
 GTA02 situation.
... so there is no such thing as a proven (good) GTA02 situation. Only proven 
thing is even USB charger specs allow for voltage transients we can not 
handle.

 If someone can actually show that GTA02 style 
 arrangement leads to product failure in normal circumstances then it
 makes it clear we need to do better.  But it seems thousands of users
 are proving it's robust enough already.
False. And false. See above. The possibility to connect random power supplies 
to powered hubs is proof enough, it's self-evident.



 Why add reverse voltage 
 protection when nobody seems to have reversed the voltage on their USB
 connector to date?
False. I read a report of a user thanking the hw-EE for designing such a 
robust device, as he actually applied voltage reverse and device survived. 
Dunno why it did, you are free to ask Wolfgang for 100 devices to do a mass 
test and prove we don't need additional protection against that. But wait, I 
think 100 broken devices are more expensive than decent reverse protection 
for 250.000 to 500.000 devices, and even the time I spent for these messages 
is worth protection for another several 1000 probably. So why not just let's 
do it?

 
 Still one part of what Joerg has been talking about he characterized as
 different component selection so it was more robust, that sounds fine if
 it is not adding expense / size.
Though you were bitching at it from very beginning, and it never would have 
happened if we listened to you. And, strange enough, all of your posts sound 
like you never had a chance to look at the GTA03 schematics and changes in 
there by yourself. :-/
Was the original USB-design yours, so you feel you have to fight for it with 
claws and teeth, despite it has ABS.MAX(!!!).ratings obviously much too close 
to normal operating conditions? That's clearly a faulty design, no EE would 
feel like good enough with it, absolutely no matter whether it already 
shows breakage in the field, or just is so close to the edge that it's easy 
to see it very likely will eventually.
BTW: please do the exercise and apply all your basic objections raised in this 
case to your suggested uC. ;-)

cheers
jOERG



signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: No blinken lights...

2008-08-30 Thread Joerg Reisenweber

Am Sa  30. August 2008 schrieb Werner Almesberger:
 Monkey + keyboard =
  For GTA02, use a really slow PWM ?
 
 Duh. Kinda hard with the clock stopped ...
Darn, no way to keep this clock alive???
I always thought this would be method of choice to flash or dim LED during 
suspend :-/
PCF50633 has some blinken-option. Alas we didn't connect it :-(

/jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GTA02 C4110/1 replacement?

2008-09-12 Thread Joerg Reisenweber

Am Di  9. September 2008 schrieb Al Johnson:
 On Monday 08 September 2008, you wrote:
  On Mon, 8 Sep 2008, Al Johnson wrote:
   Some time ago Joerg (IIRC) suggested it might be possible for the
   brave/foolhardy to replace the undersized caps in the headset output 
with
   something more suitable, or even with audiophile esoterica like Black
   Gates. Looking at the schematics I see these are C4110 and C4111 which
   appear to be located under the can that has the bluetooth module stuck 
to
   the top of it. So how easy is it to open and close this can without
   breaking anything?
 
  Hi,
 
  I tried, just to see if I could do it, to add a capacitor in parallel to
  the VB_SYS one: this is the solution the OpenMoko-people were researching
  to get rid of the
  gta02-won't-boot-on-an-empty-battery-even-with-usb-connected-thing. My
  experience: Don't do it unless you have experience with soldering tiny
  SMD-stuff, and the tools to do it. It's almost trivial to destroy stuff if
  you don't have the experience.
 
  (btw, I made pics of my endeavour; if anyone wants to see them, just raise
  your hand and I'll upload them.)
 
  Jeroen
 
 I've done the odd bit of rework on tiny SMD stuff before, so that's not so 
 much of a worry. I'm more worried about breaking something while lifting the 
 lid, especially with the bluetooth module where it is.

I lifted quite some can lids, by using a small knife or screwdriver (knife 
works better).
There's no issue with BT on lifting the lid, you just need 10 minutes of calm 
repeating same effort until you finally succeed.

Capacitors are the right ones (IIRC), you cam simply solder some wires to 
them, and route those to any place where you are able to position decent 
ones. You even might cut a small hole to the can for this purpose.

Or you just short them, and place the real good ones inside your headset jack 
outside of GTA02 ;-)


Please come up with a photo footage on your rework, as I fear I don't find the 
time soon to do that myself. :-)
You got schem and component placement. It should be easy ;-)

cheers
jOERG

ps: you also might want to short the 33R, they're useless as soon as you got 
decent C (needed for GSM-DL firmware flashing via hs-connector, if at all)


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise buzz issue

2008-09-12 Thread Joerg Reisenweber

Am Do  11. September 2008 schrieb Torsten Sievers:
 Hi Joerg,
 
 good work so far. do you have any update on this?

Well, recent reports from actual lab in Taipei are fuzzy and sparse (I 
unfortunately can't reproduce the buzz-issue here at my european lab), but it 
sounds like we can confirm it's a viable fix to cut pin4 of JK4401 and 
connect the mic signal to this trace somewhere else with a bead (even for 
headset connected :).
I'm about to test a rework-recommendation (involving Dremel/Proxxon) that's 
not including desoldering of JK4401, which is a really difficult task for 
everybody not equipped with a 4500EUR ERSA-SMT_rework station (at least if 
you care about not breaking the whole device during rework).
ATM I get low priority and few support on this from the company, as everybody 
is busy with GTA03 (and I'm with 04 ;-). But stay assured I'll not stop on 
the issue until I find I got to *some* kind of an end of the story.

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise buzz issue

2008-09-16 Thread Joerg Reisenweber

Actually Andy explained the pin3/pin5 issue.
From what I understand, with removed receptacle and 3-5 short, your buzz 
actually vanished, no? That's good news.

For the suggested rework, that's exactly why I bought a Dremel couple of days 
ago ;-)
You described my plans to the smallest detail.

Contrary to Andy I don't hope for eventual enlightenment somewhere in future. 
Especially since no one than me is examining the whole issue, and I'm sure 
there *is* *no* other way for existing devices.
If you got the fox on the farm, you don't investigate how it's actually 
killing the chicken, rather you simply fix the hole in the fence.

cheers
jOERG


Am Di  16. September 2008 schrieb Angus Ainslie:
 On Tue, Sep 16, 2008 at 7:23 AM, Andy Green [EMAIL PROTECTED] wrote:
 
 
 
  BTW props to you sir for jumping in there and start experimenting with
  jack removal, that is not so trivial to think about for a customer.
 
 
 I'm not the one who actually took the part off. I left it to far more
 capable hands in my office. I would also strongly recommend that no one else
 try this unless you are high skilled at soldering and board rework. The guy
 that did it for me has at least 10 years experience dealing with this kind
 of thing.
 
 Angus
 




signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise buzz issue

2008-09-17 Thread Joerg Reisenweber

Am Mi  17. September 2008 schrieb Andy Green:
 Somebody in the thread at some point said:
 | Actually Andy explained the pin3/pin5 issue.
 | From what I understand, with removed receptacle and 3-5 short, your buzz
 | actually vanished, no? That's good news.
 |
 | For the suggested rework, that's exactly why I bought a Dremel couple
 of days
 | ago ;-)
 | You described my plans to the smallest detail.
 |
 | Contrary to Andy I don't hope for eventual enlightenment somewhere in
 future.
 | Especially since no one than me is examining the whole issue, and I'm
 sure
 | there *is* *no* other way for existing devices.
 | If you got the fox on the farm, you don't investigate how it's actually
 | killing the chicken, rather you simply fix the hole in the fence.
 
 Our incomplete understanding does not lead to a solution for headset mic
 buzz nor any security about future designs.
You're sure about that?

 One way or another we need 
 to penetrate those mysteries a bit deeper up to WM8753.

If anybody thinks he needs to learn why it's bad to route RF into a can that's 
designed to keep RF outside, go ahead! Those cans are used *because* not even 
the chip designers can predict what will happen when their chip is flooded 
with 1800MHz. If they could, they could change chip design in a way we 
wouldn't need cans anymore ;-)
Basically it's always the same problem: RF hits a non-linear component (like 
crystal-detector back in ~1900, or any P-N-zone [aka diode] in a 2- or 3-pole 
(chip-)component nowadays), and there it gets rectified and 
introduces DC-current (actually audio-frequency LF-current) in parts of the 
circuit where we absolutely don't want to see it. You can't do anything else 
than just stop RF *before* it reaches this critical point. Typical points to 
stop RF are entrance of external antennae (=short or long unshielded wires) 
to PCB, and **entrance of traces into can**.

We don't want to learn how to make RF behave inside a can, simply because 
we'll never win. RF is a beast, mostly you just can't tell what it will do 
until you actually tried.

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise buzz issue

2008-09-17 Thread Joerg Reisenweber

Am Mi  17. September 2008 schrieb Andy Green:
 Which pins on WM8753 are affected by what in order to make this buzz?
Wolfson micro headquarters is in Edinburgh AFAIK. Probably you'll find someone 
there who might be interested in your findings on that.
Please don't forget to specify things like amount of soldering tin between 
chip and PCB and distance of chip upper surface to can lid, when starting 
investigation, so the results about chip-internal effects when applying RF to 
single pin are reproduceable.

For the rest of us, the simple rule there must not be *any* RF *anywhere* on 
WM8753 should suffice to do a decent working buzz-free design.

/j



signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise buzz issue / ways forward

2008-09-22 Thread Joerg Reisenweber

Am Mo  22. September 2008 schrieb Andy Green:
 Somebody in the thread at some point said:
 
 | and *then* continue to look for good fixes for already existing ones,
 this
 | request gets torn down by an immediate vivid discussion about
 contamination
 | pathes etc., leaving impression to TPE EE we are not on same page
 about doing
 | new PCB to include EMI-filters on 3 contacts of JK4401.
 
 If we're making an A8 today we should add them, solely on the basis
 that's the only thing we found that affects it at all.  But, I don't
 think we make an A8 today.
 
 What we need to increase our understanding of the whole problem if we
 can in the meanwhile and see if we can find more attacks elsewhere and a
 different way to come at it.  That is why the difficult question about
 paths keeps returning.  Really the bead impact is clue to the larger
 problem structure, not a solution in itself (although if we don't get
 any further, that's all we have to play with).
 
 -Andy
 

I definitively resign.
/j



signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise buzz issue

2008-09-29 Thread Joerg Reisenweber

Am Mo  29. September 2008 schrieb Andy Green:
 Somebody in the thread at some point said:
 
 | Got around to try it just today.
 | The problem for me with testing is that I (too) have a pretty good
 | signal where I life (Actually orignating about 300m away ;) ), so that
 | if there is buzz it is relatively silent.
 | To reproduce it reliably I just went into the cellar and did a longer
 | test call. Interestingly the buzz was sometimes pretty loud and
 | sometimes hardly present which did not seem to coincide with the signal
 | strength. Actually once I noticed the buzz getting louder when the
 | signal got stronger oO. What I annoyingly had all the time was a pretty
 | loud echo though :(.
 
 I know what you mean about it coming and going, seemingly disconnected
 from what you are doing to the phone.
 
 I was looking at the VB_SYS rail during the buzz time a couple of months
 ago, it seemed to me the buzz came and went according to what I saw on
 VB_SYS.  But this was an A5 revision.

I will include this to my mail signature:
Buzz obviously is related to TRANSMIT-power of mobile. Transmit power is 
remote controlled by the base station, so the signal BS is receiving meets 
BS' taste. There is *no* direct relation between RECEIVE-signal strength as 
reported by signal meter on mobile, and the way BS decides to set he TX-power 
of mobile to.
Obvious example: when very remote of a strong BS, you might see good signal 
strength, but transmitter of mobile has to power up to the limit. When close 
to a BS of a small cell (usual situation in urban areas), you might see weak 
signal strength, but nevertheless mobile needs low tx-power to reach the 
nearby BS.
Then when BS sees some bad noise spoiling the signal from your phone, BS will 
decide to level up TX-power of your phone, and buzz increases without any 
change at all in your test setup.
That's also the reason why replacing original antenna with a piece of wire 
doesn't really change buzz situation: BS is leveling TX-power so 
the reduced TX-RF-field is attenuated to be same as before, though 
transmitter-amp is burning more power to achieve this identical TX-strength - 
so this wire-antenna-test actually is a proof for OTA-injection of buzz, as 
it has to yield *more* buzz if it was by internal coupling via RF or DC.

It's difficult to test in real live, you absolutely can't control the setup.



 
 | As for the shorted plug: If there is buzz it amplifies it a tiny bit, if
 | there is no buzz it doesn't seem to induce buzz, but it definitely does
 | not seem to make things better.
 
 At high frequencies shorts with some loop area don't necessarily have
 that low an impedence.
 
 What did you actually short to what, everything to the 0V pin really?

The most easy way to short it is to use a copper wire of correct diameter and 
insert that instead of a plug (don't push it in too far ;-) ).
I don't expect this will yield a good result, as our tests to short 
JK4401:pin6 to GND internally also didn't help. Be aware: this isn't exactly 
GND plane, but in fact one half of the antenna dipole. RF isn't only at 
antenna, but spreads all over the device electrical surface.

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise buzz issue

2008-09-30 Thread Joerg Reisenweber

Am So  21. September 2008 schrieb Uwe Klein:
 On 9/21/08, Werner Almesberger [EMAIL PROTECTED] wrote:
  Andy Green wrote:
One interesting thing would be stick a tracking generator on the GSM
antenna, put it near the headphone socket in a repeatable way, stick
spectrum analyzer probe on the victim net, and sweep them to get a
display of coupling efficiency vs frequency.
 
 
  Do you think this will work ? I thought of using a tracking generator
   when I wrote that mail lamenting that Joerg didn't have a signal
   source, but then I realized that almost all tracking generators have
   their maximum output at about 0dBm, while our troublemaker should be
   more like 30dBm.
 
 I had thought about using the FR as an energy sink.
 Using a 4pole networkanalyzer and a pair of antenna
 in a grid dip meter style arrangement.
 This should indicate all absorbtive elements.

A very cute test setup.
Anyway I don't exactly see what we have learnt once we know all dips by name, 
err frequency and dB. I'd guess we get a lot of dips, and we can't tell what 
element caused them, and especially we don't learn anything about audio 
contamination path. Even less we learn something *new*.
Werner's original proposal seems somewhat more result oriented, alas all this 
fails when attaching probe to the victim net, due to total change of 
RF-properties (probe has some pF! need to open can, etc). So probably the 
most helpful test would be to use a +36dBm generator at 850/900/ 
and record buzz by arecord piped to ssh-stdout to external PC, so you can 
level up generator and see what dBm you need at different frequencies to 
start buzz. Basically exactly the tests I already did in TPE, though I had to 
use a second phone for generator purpose, and this was rather clumsy and not 
very reproduceable.

Also direct coupling of RF to JK4401:4 at a moderate level might be a way to 
go, then check with scope/spectralizer all the pins and pads inside can, and 
get an idea of where RF jumps to from primary path (if any). Again we won't 
learn anything about how we could improve things, other than KEEP RF OUT of 
CAN, i.e. away from non-linear audio-circuits.

Anyway, I'm looking forward to read your report on test results.

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Neo1973 WM8753/Alsa Configuration

2008-10-01 Thread Joerg Reisenweber

Am Mi  1. Oktober 2008 schrieb Mark Brown:
 The controls for the WM8753 itself are all defined in
 sound/soc/codecs/wm8753.c in the kernel source - they're all done with
 macros which map them into register fields in the codec.

I tried to find name of a registers this way, but this code is so nested and 
cryptic and poorly commented, I really didn't success to understand the logic 
behind the data structures and defines.

@Kyle: you could try to learn from a diff between the two state files (plus 
maybe a third one, for reference to distinguish the specific controls to set 
for a particular state)

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Neo1973 WM8753/Alsa Configuration

Am Mi  1. Oktober 2008 schrieb Mark Brown:
 On Wed, Oct 01, 2008 at 05:13:37PM +0200, Joerg Reisenweber wrote:
 
  I tried to find name of a registers this way, but this code is so nested 
and 
  cryptic and poorly commented, I really didn't success to understand the 
logic 
  behind the data structures and defines.
 
 The actual register definitions are pretty direct AFAICS - the text
 string with the user visible control name is immediately next to the
 register names - for example:
 
   SOC_DOUBLE_R_TLV(PCM Volume, WM8753_LDAC, WM8753_RDAC, 0, 255, 0, 
dac_tlv),
 
 is a control callled PCM Volume at bit 0 with value up to 255 in the
 LDAC and RDAC registers.  Obviously, YMMV but it shouldn't be too hard
 to find the user-visible name for a register bit or vice versa, I'd have
 thought.

60sec reality check:
PCF50633UM2.00.pdf - search RDAC - error: no occurrence found

Also I'm pretty sure the user visible control name isn't exactly what you 
get to see in alsamixer for example. Furthermore they are often wrong as they 
don't regard our particular hw-setup, where GSM-mic sensitivity is something 
like mono sidetone playback volume or such weirdness.
The situation resembles using a genuine PS/2 mouse driver for a synaptics 
touchpad. I really don't think there is any value or sane rationale behind 
using a generic upstream driver for a very OM-specific hw-design, the usual 
way for all hardware is manufacturer of device creates tailored-to-suit 
drivers for their product, admittedly based on chip manuf's generic chip 
driver sources usually.

/jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Neo1973 WM8753/Alsa Configuration

Am Sa  4. Oktober 2008 schrieb Joerg Reisenweber:
 Am Mi  1. Oktober 2008 schrieb Mark Brown:
  On Wed, Oct 01, 2008 at 05:13:37PM +0200, Joerg Reisenweber wrote:
  
   I tried to find name of a registers this way, but this code is so nested 
 and 
   cryptic and poorly commented, I really didn't success to understand the 
 logic 
   behind the data structures and defines.
  
  The actual register definitions are pretty direct AFAICS - the text
  string with the user visible control name is immediately next to the
  register names - for example:
  
SOC_DOUBLE_R_TLV(PCM Volume, WM8753_LDAC, WM8753_RDAC, 0, 255, 0, 
 dac_tlv),
  
  is a control callled PCM Volume at bit 0 with value up to 255 in the
  LDAC and RDAC registers.  Obviously, YMMV but it shouldn't be too hard
  to find the user-visible name for a register bit or vice versa, I'd have
  thought.
 
 60sec reality check:
 PCF50633UM2.00.pdf - search RDAC - error: no occurrence found

ooops, sorry :o)


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GTA03 revision available

Am Sa  4. Oktober 2008 schrieb Werner Almesberger:
 [EMAIL PROTECTED] wrote:
  From what I know, I would expect it to be available in the fall
  of 2009. But this is only my guess.
 
 5Q2009 is actually when we plan to release the Neo Lockdown, running
 Proprietarix licensed from SCO(tm), SIM-locked to Iridium, and with
 pay-per-use applications. Since we're all about freedom, you will be
 able to change the battery as you like, but it will only release its
 charge if its serial number matches the one etched into our
 custom-built phone-on-a-chip(r).
 
 RD hasn't started yet, but we'll get to it as soon as we're done
 filing all those software patents.

Damn, Werner! The Iridium-SIMlock story is under heavy NDA :-(
Are you speculating with Boing shares?
/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GTA03 revision available

Am Sa  4. Oktober 2008 schrieb Mike (mwester):
 Joerg Reisenweber wrote:
  Am Sa  4. Oktober 2008 schrieb Werner Almesberger:
  [EMAIL PROTECTED] wrote:
  From what I know, I would expect it to be available in the fall
  of 2009. But this is only my guess.
  5Q2009 is actually when we plan to release the Neo Lockdown, running
  Proprietarix licensed from SCO(tm), SIM-locked to Iridium, and with
  pay-per-use applications. Since we're all about freedom, you will be
  able to change the battery as you like, but it will only release its
  charge if its serial number matches the one etched into our
  custom-built phone-on-a-chip(r).
 
  RD hasn't started yet, but we'll get to it as soon as we're done
  filing all those software patents.
  
  Damn, Werner! The Iridium-SIMlock story is under heavy NDA :-(
  Are you speculating with Boing shares?
  /j
 
 Iridium, huh?  I just knew *somebody* would buy up all those satellites,
 and put them to some nefarious use!
 
 Mike (mwester)
 

Yeah, actually that's been Openmoko ;-)
But Boing isn't really interested in selling them, and the CIA is a tough 
opponent on negotiations.

/j




signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: WLAN signal strength - good or bad ?

2008-10-04 Thread Joerg Reisenweber

WLAN is RF and thus again voodoo. I only know I have similar puzzling results 
whenever I compare any 2 randomly chosen WLAN-Xceivers.
10cm of movement may change situation totally, and the sending out of beacons 
isn't very comparable between different APs.
To make things worse, not only the beacons are sent a few times/sec, but also 
the DUT-xceiver has to scan 11~14channels. So one DUT may just hit a good 
beacon not spoiled by interference from another AP on same channel, while the 
other DUT might be unlucky to read any beacon of same AP, just 200mSec later, 
when it's about to scan same channel.
Then it seems there are a multitude of proprietary filter algos in the 
WLAN-chipset FW, that have great influence on what's reported to and by the 
driver, and probably there are differences in the drivers themselves as well.

It's mere chaos and you won't get reproduceable results, you can just do 
statistical analysis over a huge number of samples.
Reported dB and % values are usually not standardized between drivers, and 
I've seen a lot of bogus values being reported.

Best test I found for WLAN performance is actual throughput resp Quality of 
Signal (though the later isn't usually reported in a reasonable way so you 
could compare different WLAN-chipsets)

cheers
jOERG




signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise buzz issue- Stupid Question... Are Bluetooth headsets affected?

2008-10-12 Thread Joerg Reisenweber

Am Mo  13. Oktober 2008 schrieb [EMAIL PROTECTED]:
 Sorry about the dumb question. I was just wondering if bluetooth headsets 
would be affected by this buzz problem.

No. Will work without buzz
/jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GTA04 SoC/CPU and LCD size

2008-10-30 Thread Joerg Reisenweber

+1 
for some sort of transflexive screen that displays (a maybe somewhat reduced 
set of) information without backlit.

/j


Am Do  30. Oktober 2008 schrieb Alastair Johnson:
 Uwe Klein wrote:
  Now for something completely different:
  
  is a OLPC / Pixel Qi type reflective LCD an option?
  http://www.pixelqi.com
 
 I've been thinking the same thing. The poor daylight readability is the 
 only thing I don't like about the current screen, and is a real issue 
 when it's on my bike. Reduced power consumption would be a bonus.
 
 ___
 hardware mailing list
 hardware@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/hardware
 




signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise buzz issue

2008-10-30 Thread Joerg Reisenweber

Am Mi 29. Oktober 2008 schrieb Angus Ainslie:
On Wed, Oct 29, 2008 at 12:08 PM, Ole Kliemann
[EMAIL PROTECTED] wrote:

Hi Joerg and others,

I haven't followed the whole thread as I only understand 1%. So just one
quick and dirty question:

I have the two years EU warranty and am going to send my FR to my
distributor anyway because GPS is not working with the internal antenna.
(Independant of SD card.)

So if I send it in, is there any fix that could be applied for the
buzz? Or is it worth to wait, say another week, because there will be
something then?

And - if you allow me to be off-topic - is there any improvement fix for
the headphone jack? I mean this hipass-filtering issue making music
sound quite tinny.

Thanks!
Ole

Hi Ole,

I don't know whether Joerg has attempted the hardware fix yet.
Please see the whole thread to find we did quite a number of tests to verify
it, in TPE.

I finished
mine yesterday. Attaching the bead to the pad of pin 4 does NOT fix the GSM
buzz issue.
Attaching the bead is *not* the fix exactly, cutting the connection from
JK4401:4 to coppertrace is considered the fix.
Anyway it seems you tried to achieve this by cutting the contact from JK4401
(your first picture). Alas it's not clear if you correctly isolated pin4-pad
on PCB, so to me it looks like you soldered the bead on the pin4-pad and
maybe you just shorted the tiny gap between PCB-pad and the metal-stub where
you cut off pin4-contact on JK4401, while soldering the bead.

Cutting the contact sure is a good thing, anyway I recommend to isolate pin4
PCB-pad by some plastic, so it is securely NC and in some distance to
JK4401:4 metal spring. (see:
http://people.openmoko.org/joerg/GSM_EMI_noise/noise_stopped_by_cut_pin4/JK4401_isolate_pin4__2.jpg
)
Then do first test to find buzz is gone.
Then place bead to pad of R4404 NC, or even piggyback it to C4405, and connect
to upper golden contact of JK4401, above pin4. (Please note you need the bead
only for hs mic function, which may still be broken when using it during GSM
RF activity)

There are a couple of pictures.

Connector with pad 4 removed:

http://handheldshell.com/connector.jpg

It's a little hard to see, in this photo the bead is soldered standing up on
pin4 with a jumper wire from the top of the bead to the side of the headset
plug.

http://handheldshell.com/board.jpg

With this change the buzz is just as bad as ever.

Angus

--
Angus Ainslie
http://www.handheldshell.com/

signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise buzz issue

2008-10-30 Thread Joerg Reisenweber

Am Do  30. Oktober 2008 schrieb Ole Kliemann:
 Thanks for the answer!
 
 The point is, i certainly won't do the fix myself. ;) I will send my
 device to my distributor on warranty.
 
 On Thu, Oct 30, 2008 at 12:11:47PM +0200, Joerg Reisenweber wrote:
  Seems you always could upgrade to the 'botch' fix found in A7 (It 
*should* 
  work, as our TPE engineers found it worth to implement in A7 ;-):
 
 So as this fix is officially approved,

That's *your* way to read my words ;-)
My posting contained nothing official nor any approvement.

 I assume my distributor will 
 either be able to apply it or provide me with an A7. Gonna check with
 them soon.
 
   And - if you allow me to be off-topic - is there any improvement fix for
   the headphone jack? I mean this hipass-filtering issue making music
   sound quite tinny.
  a) place some decent 100uF (or as high cap as feasible) parallel to C4110 
and 
  C4111. Make sure you don't create another contamination path for RF 
creeping 
  inside big can - maybe use a ferrite ring to block RF next hole where you 
  route some wires from those big caps inside can to C4110/11.
  b) *short* C4110 / C4111, and insert the 100uF somewhere else in 
audiopath, 
  b1)e.g. near R4405 / R4407 (you can even replace these R by 100uF 
  capacitors).
  You should remove R4117 and R4117 then, and instead place these 1k from 
  JK4401:pin2 and pin3 (! for JACK_INSERT function) to GND
  b2) or even place the 100uF outside FR in the housing of your hs-plug or 
  2.5-3.5mm adapter
 
 Is this somewhat official? 
Nope.

 Is it included in any newer revision? 
For sure not, as any official fix (that may or may not be included in A7, 
I'm pushing it but result is somewhat... hmm, limited) for sure simply will 
rearrange layout to make space for decent 100uF in place of the former 1uF 
C4110/C4111.


/jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: [sound]: capacitor that act like a high-pass filter and so removes the bass on the headphones jack

2008-11-15 Thread Joerg Reisenweber

Am Sa  15. November 2008 schrieb [EMAIL PROTECTED]:
 Hello, I've the same issue as described here:
 
http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware_Issues#Known.2FAccepted_Issues
 That is to say the Poor low-frequency audio response with low-impedance
 headphones problem...
 On IRC I was told that was the fault of a capacitor that lies between the
 audio chip and the headphones jack that is too low and act like a
 high-pass filter and so removes the bass...
 
 This issue is very problematic for me:
 I've a pma430 that I use like an audio player(linux device with
 proprietary kernel modules and an old proprietary version of qtopia)...but
 it's an old device...and one day the battery will die...
 Moreover it has a lot of bugs that I can't get rid of:
 *mplayer for the pma430 is buggy and I don't have its sources(it's a
 special port because the sound drivers are buggy or specials...)
 *the default player is buggy and I often have to restart the device
 *the suspend button is often pressed when the device is in my pocket...and
 because of the proprietary nature of the device I don't think this could
 be changed...otherwise the openpma devellopers would have changed that...
 So buying an openmoko I thought that I would get a device that would
 replace it as:
 *a real GNU/Linux pda(done(the compiler of the pma430 couldn't be changed
 because of a kernel bug and the kernel couldn't be changed because of the
 proprietary modules,but with openmoko we have openembedded and a lot of
 software))
 *an audio player(here's the problem)
 
 The problem is that the software fix suggested by the wiki isn't
 sufficient for proper audio quality...
 
 So what are my options?
 solder myself the capacitor isn't an option...I'm not skilled enough nor
 have the right soldering iron(Long time ago I've broken a graphic card
 trying to do a mod that would make the nvidia drivers recognize the card
 as a quadro card...(the card was sometimes recognized by the 3d driver and
 sometimes not))
 So what sould I do?
 find a shop or someone that would do it for me(I live in Milan in Italy)?
 use the guarantee(I bought it at bearstech)?
 Or would a better software fix be possible(such as re-encoding the ogg
 with special filters?,but that would be problematic as it would use a lot
 of space for keeping the files on my computer...but if it's the only
 option I'll use it)
 adding an external sound card isn't an option either because if I use it
 in my home on a hifi-set I would not be able to feed the openmoko in
 power(as the usb port would be taken by the audio card) or if I use it
 outside...a sound card isn't very compact...
 By the way for determining the version of my hardware, I think I've got
 the hardware fix for the GPS and I bought a released version of the GTA02
 Thanks a lot in advance for your help.


Sorry the audio is definitively broken due to the capacitor issue you're 
mentioning. There is no sw-fix either.
You may get (semi)decent audio by:
o- using a home-stereo line in, which has 1k input impedance
o- using high impedance headphone (600 Ohm)
o- do a rework on the capacitors (there are different ways to do that, all 
need excellent soldering skills)
o- use a bt-headset

very sorry I didn't achieve to fix this for MP yet
cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: [sound]: capacitor that act like a high-pass filter and so removes the bass on the headphones jack

2008-11-15 Thread Joerg Reisenweber

Yes, sounds like a good idea (input impedance should be (much)  [GT] 1000Ohm 
though, not 1k)
This adapter also could implement some hw-equalization for the highpass-filter 
created by the 1uF*(1/(1/1k + 1/(33R + adapter-impedance)). (where, in 
sequence, values are from: C4111:1u, R4117:1k, R4407:33R. Right channel 
analogue)

Requests for assistance welcome.
cheers
jOERG

Am So  16. November 2008 schrieb Scott Carlson:
 Would also be possible to create a small inline adapter for head set that
 have 1k input impedance? It may be convenient to make a batch and sell them
 cheap? (As a non-intrusive) hw fix.?
 
 SCarlson
 
 
 
  Sorry the audio is definitively broken due to the capacitor issue you're
  mentioning. There is no sw-fix either.
  You may get (semi)decent audio by:
  o- using a home-stereo line in, which has 1k input impedance
  o- using high impedance headphone (600 Ohm)
  o- do a rework on the capacitors (there are different ways to do that, all
  need excellent soldering skills)
  o- use a bt-headset
 
  very sorry I didn't achieve to fix this for MP yet
  cheers
  jOERG
 
  ___
  hardware mailing list
  hardware@lists.openmoko.org
  http://lists.openmoko.org/mailman/listinfo/hardware
 
 
 




signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: [sound]: capacitor that act like a high-pass filter and so removes the bass on the headphones jack

2008-11-28 Thread Joerg Reisenweber

Am Sa  29. November 2008 schrieb Andy Green:
 Somebody in the thread at some point said:
 | I think I understand. I built one 10 F capacitor into the adapter (at the
 | mass), so the problem with the headphones should be fixed. I also
 measured a
 | 1,59V current at the capacitor when plugged in and silent. Sound is
 good as
 | before.
 |
 | It's beginning to sound very appealing.  I was very disappointed to
 | discover that my FR is unusable as an MP3 player (and I'm not demanding:
 | I usually find 64Kb/s Vorbis files good enough for such a use).
 |
 | Unfortunately, the internal speaker sounds really bad now (distorted).
 | So I think i'll remove the silver again and find somebody who can help
 | me with the soldering...
 |
 | Hmm... why does it distort the interal speaker?
 
 With the caps the transducer experiences -~1.5V .. +~1.5V worth of
 deflection down and up; without the caps it experiences 0 .. ~3V
 worth all up.  So it's physically unable to deflect enough linearly I
 would think.

Please note the internal speaker isn't connected via the 1uF capacitors. 
See SPK LOCATION:41XX page6 schematics GTA02.
So shorting them will not directly cause a different DC-offset situation on 
internal speaker, and shouldn't make any trouble for it.
A short to GND when applying the silver-varnish on the other hand might cause 
the distortion you have heard.

I won't recommend shorting the DC-blocking capacitors. A decent rework/fix 
comprises finding a place for 2 100uF, and then connecting these in parallel 
to the 1uF, preferably by by shielded two-wires-cable. If these big 
capacitors are located outside can, I strongly suggest to place a ferrite 
bead directly on the hole where the cable enters he can, to block RF from 
entering the can (homebrew buzzissue).

BTW: be aware you easily may destroy headsets or speakers by applying DC for 
prolonged periods of time. Strongly deprecated.

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Bug #1024 related power measurement of the GSM modem

2008-12-02 Thread Joerg Reisenweber

Am Di  2. Dezember 2008 schrieb Dieter Spaar:
 Hello Stefan,
 
 Stefan Schmidt wrote:
  To follow up on the #1024 traces. I fear you are still not able to 
reproduce the
  re-camping?

 
 No, I cannot reproduce it here. It seems that it requires a special GSM
 net situation.
 
  From the PCO2 logs you made, it look like this without applying the
 AT%SLEEP=2 workaround (Thank you for allowing to post this trace
 overview). All times are relative, CID is the cell ID:
 
 00:06:04:667   MMR_REG_CNF received: LAC: 0020, CID: DACC
 00:09:37:249   MMR_REG_CNF received: LAC: 0020, CID: DAB8
 00:11:45:560   MMR_REG_CNF received: LAC: 0020, CID: 00CA
 00:12:41:293   MMR_REG_CNF received: LAC: 0020, CID: C834
 00:14:24:681   MMR_REG_CNF received: LAC: 0020, CID: DACC
 00:14:48:234   MMR_REG_CNF received: LAC: 0020, CID: DAB8
 00:15:23:502   MMR_REG_CNF received: LAC: 0020, CID: 00C0
 00:16:22:414   MMR_REG_CNF received: LAC: 0020, CID: DACC
 00:16:49:465   MMR_REG_CNF received: LAC: 0020, CID: 00CA
 
 It seems that you have at least five cells for your network around
 which can be received with a similar level. [ Hey, I think I have
 buy more BS-11 base stations and  install all of them to get
 something similar here ;-) ]
 
 On a first look the cell re-selections are done because
 the GSM modem has decided that a different cell is better
 than the current one. I would say that this is not necessarily
 a wrong behavior of the GSM modem.

Please check C1/C2 threshold levels. Usually this *is* an erratic behaviour of 
GSM.

 
 The situation is similar with the AT%SLEEP=2 workaround applied:
 
 00:03:44:457   MMR_REG_CNF received: LAC: 0020, CID: DAB8
 00:03:58:336   MMR_REG_CNF received: LAC: 0020, CID: 00CA
 00:04:32:477   MMR_REG_CNF received: LAC: 0020, CID: DACC
 
 (The trace is shorter so there are not that many cell re-selections).

So we see the same unpleasant behaviour here as well :-(
Seems sleep=2 won't stop it.
Is this really an active complete cell reselect? Could you check if there's 
GSM TX activity each time we see MMR_REG_CNF received: please.


cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Fwd: No more optimization team

2008-12-15 Thread Joerg Reisenweber

100% ACK


Am Di  16. Dezember 2008 schrieb Werner Almesberger:
 Joerg Reisenweber wrote:
  Are you living in an area where many people use their cellphone, but only 
few 
  BS around? We have some cloudy theory this might be a trigger for #1024.
 
 Perhaps it would be good to collect some more specific reports of the
 kind of settings ?
 
 This seems to be a bit similar to the WLAN problems that eventually
 turned out to be linked to having multiple access points, but the
 picture remained vague until we had a large enough number of fairly
 detailed usage stories.
 
 With GSM, things are more complex, because it's harder to know what
 the network is like. But getting a first overview may help to find the
 next, more specific questions to ask, etc.
 
 - Werner
 




signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

GSM #1024 issue

2008-12-16 Thread Joerg Reisenweber

Mickey,
could you connect an external GSM-antenna and check if there's any difference?
Preferably connect the external antenna while actually encountering a #1024, 
and see whether it stops, or otherwise changes characteristics.

many thanks
cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM #1024 issue

2008-12-16 Thread Joerg Reisenweber

Am Mi  17. Dezember 2008 schrieb Michael 'Mickey' Lauer:
 Am Tuesday 16 December 2008 20:33:42 schrieb Joerg Reisenweber:
  could you connect an external GSM-antenna and check if there's any
  difference? Preferably connect the external antenna while actually
  encountering a #1024, and see whether it stops, or otherwise changes
  characteristics.
 
 Did that months ago when I first encountered the problem -- no change 
 whatsoever.

Thanks!
Great, so we can exclude a whole bunch of causes that are *not* responsible 
for #1024.
In fact this reduces it to the GSM-FW and the OTA-protocol.

/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: MICBIAS buzz injection

2009-01-14 Thread Joerg Reisenweber

We have an issue regarding HW-driven max output level of the A5..A7-mic vs max 
input sensitivity of Wolfson 8753. Anyway this is about some 20dB missmatch, 
and regarding the amount of noise/distortion the mic introduces by itself 
this won't spoil our overall signal quality balance. (you might get sth like 
a 10..14 bit resolution)
8753 has such a low noise floor even at A/D conversion (see datasheet) you 
won't recognize or notice the problem, as you still get much better than 60dB 
S/N. Just boost the digital signal to 0dB and everything will be fine. (I 
apologize for this botch, but it's not really a problem. Builtin mic isn't 
HiFi anyway, for bootleg record purposes please use a decent stereo mic 
connected via USB)

And yes, of course you can record from mic by sw. What do you think we 
designed this device for ;-) ?

cheers
jOERG



Am Mi  14. Januar 2009 schrieb Erland Lewin:
 If you could record from the microphone by software on the Freerunner, that
 would be great.
 
 I would like to see confirmation that speaking at a conversational level to
 the microphone will give a nice signal level that fully uses the 16 bit
 range, and also show to some extent the degree of noise at the microphone. I
 did some recording tests a few months ago, and was never able to get a good
 signal level.
 
 Because of the degree of complexity of the audio path (both hardware 
 software), I think it would be nice if OpenMoko had such test software to
 verify that microphone recording works well, and that the level is ok as
 part of your test suite.
 
 Regards,
 
 Erland
 
 2009/1/13 Werner Almesberger wer...@openmoko.org
 
  Joerg and I discussed today how to verify that the MICBIAS buzz rework
  was done properly. Joerg had a very interesting idea: by toggling the
  codec's MICBIAS output, we should be able to create noise that would
  vary depending on whether the rework has been done. He asked me to
  adapt one of my I2C-tweaking programs for this purpose.
 
  Here's a little program that hammers the Wolfson as fast as it can,
  making MICBIAS oscillate at about 50Hz:
  http://svn.openmoko.org/developers/werner/wolfhammer/
 
  The result looks like this, on a non-reworked A6, measured on the
  codec side of R4305:
  http://people.openmoko.org/werner/a6-nrw.png
 
  The amplitude seems pretty small (and I have plenty of ambiental
  noise), so I'm not sure if this is good enough. To verify that
  MICBIAS was indeed being toggled, I added a 1k resistor between the
  measurement point to ground (i.e., parallel to R4305 and C4302),
  which yielded this:
  http://people.openmoko.org/werner/a6-nrw-1k.png
 
  Joerg, I hope this is useful.
 
  - Werner
 
  ___
  hardware mailing list
  hardware@lists.openmoko.org
  http://lists.openmoko.org/mailman/listinfo/hardware
 
 




signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: hardware development tool of freerunner (GTA2)

2009-02-12 Thread Joerg Reisenweber

Am Do  12. Februar 2009 schrieb aawnsd:
 
 Hi, 
 anyone who know which tool was used (CAD/CAE, schematic/pcb) do design GTA2
 and product the pdf's?
 Who to ask?
 aawnsd

Schematics and layout PCB are done using Mentorgraphics LOGIC/PADS
/jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GTA03 and E-Ink Interface

2009-02-14 Thread Joerg Reisenweber

Am Sa  14. Februar 2009 schrieb Jaya Kumar:
 ni hao and hello OpenMoko friends,
 
 Ok, to explain my interest quickly: what I hope to do is to take an
 openmoko and add an E-Ink display, possibly replacing the LCD if
 necessary. It is too early for this to be useful to people so I do not
 want to consume any significant time or effort from OpenMoko's
 developers. I'm willing to do this on my own.
 
 I'm the author of the E-Ink display controller drivers in the mainline
 linux kernel, and have been working on making broadsheetfb, the driver
 for E-Ink's latest controller behave in a way such that generic Linux
 applications can run on it without any modification. I have had some
 good initial results which I have shown. eg: videos here ( mozilla
 fennec on e-ink,  http://www.youtube.com/watch?v=k4WBdagDgSg ) and
 various articles here (
 http://highlycomposite2.blogspot.com/search/label/e-ink ).
 
 I feel I have a clear idea of how to achieve this idea of adding an
 E-Ink panel to a phone, the only constraint is that I need 22-pins of
 GPIO. I asked Harald and he had suggestions and pointed out that the
 22-pin constraint may be a serious problem. I'm willing to sacrifice
 certain other peripherals to get that count. I was searching the
 openmoko wiki for GTA03 gpio pinout or some idea of a list of signals
 that are brought to surface pads or traces that I could then tap onto.
 Is this available?
 
 I had also looked at GTA02 pins:
 https://svn.openmoko.org/trunk/doc/hardware/GTA02v4/gpio.txt
 based on that, some notes for myself:
 - abandon bluetooth 1
 - abandon sd card 6
 - abandon LCD and repurpose those LCD's interface pins that can be
 repurposed as gpio, i think this gives me about 5 pins but not sure if
 all are brought to connector (lcdvf0,1,2, lcdhclk, lcdpwren),
 - so insufficient gpio. have to use gpio extender connected via i2c or
 uart. a big latency penalty though.
 - so look at gta03 and hope for inspiration :-)
 
 Any advice and suggestions would be greatly welcome.


You need those 22 gpio *in addition* to the LCM data lines from glamo to lcm?

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GTA03 and E-Ink Interface

2009-02-15 Thread Joerg Reisenweber

Am Mo  16. Februar 2009 schrieb Jaya Kumar:
 On Mon, Feb 16, 2009 at 8:02 AM, Andy Green a...@openmoko.com wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Access to Glamo mapped region is much slower than 50ns.  But, it's 16
  bits wide.  If you were able to use all the 16 bit width, you would have
  more than enough bandwidth.
 
 Ok, with you so far.
 
 
  Here's an idea, totally abuse the Glamo framebuffer and pixel bus to
  store your bitbang sequence as video.  Then hook up each of your E-ink
  bus signals to one bit of pixel data, eg, E-ink nRD - RED0.
 
 I've lost understanding here. I have 22 signals. To talk to the
 display, I need to wiggle 3 control signals, set 16-bits of data,
 repeat to  framebuffer size, wiggle some more and then finally wait
 for an interrupt from a 4th control signal to send a command. I think
 there's no input signal on the pixel bus so Glamo won't be able to
 report the interrupt back to me. But I think it would not be a problem
 for me to put that signal on an actual gpio. So that leaves the
 problem of the 3 control signal and 16-bits of data. Is there a way
 for me to store those 19-bits of data in the framebuffer so that glamo
 can push them to the controller. I guess if glamo knows about RGB888
 and can transfer that to the pixel bus, that would work fine since I
 can just store my control sequence + data inside the 24-bits of
 framebuffer data and then get glamo to push that through. That would
 be awesome.
 
 
  Pixel data generation is synchronous in the Glamo so the edge quality
  should be good enough to clock from.  There's a PLL in the Glamo that
  can be meddled for Glamo pixel clock: it's 24.5MHz typ IIRC.
 
  Because your bus clock is also derived from pixel data, and your system
  is fully synchronous, HSYNC and VSYNC will be invisible so long as you
  return your clock to 0 (presumably) before the end of each video line.
 
 You lost me here. I have a write signal that is used to clock the data
 in for every 16-bit transfer, perhaps that's what you mean by bus
 clock. For example, a full buffer transfer involves:
 
 set chipselect off
 set data on
 foreach pixel {
 set write off
 set 16-bits framebuffer data
 set write on
 }
 set chipselect on
 
 If we treat write as a clock signal, then the clock must return to
 idle after exactly the last pixel (of the whole framebuffer) rathar
 than a whole horizontal line. I could use the vsync on the host to
 tell me when to set chipselect on if I treat that as a separate IO.
 
  There's an auto page flip feature in Glamo that can help you issue this
  data just the once, you can keep the other page at all pixels 0x00,
  then it simplifies enabling page flip and watching it do it once, then
  disabling page flip.
 
  This should give you highest bandwidth solution possible on GTA02.
 
 Ok, sounds pretty good although the level of complexity seems high.
 btw, I'd want to tell Glamo to suspend shortly after a transfer since
 it's an E-Ink display since we won't need it to be active until the
 next time we want to draw anything.
 
 Thanks,
 jaya
 

if that's a problem getting enough datalines from LCM videodata interface, you 
could use 2 pcs 16bit latch and control their CS and CLK and OE with 2 lines 
while hooking up the rest for latch data input. this way you have full 
control of all 32 (28?) output lines to a time granularity of glamo's 
pixelclock / 2. Of course with gaps during hsync where output won't change.

For the very slow e-ink display I don't see where concerns about speed of data 
transmission arise from. Anyway with the concept sketched above you just fill 
glamo's videobuffer with the signalpattern for your interleaved 2 x 16 
outputs, enable video output, and your kernel driver is idle during 
glamo bitbanging the e-ink interface data via the latches.
I could help better if I had a datasheet of the E-Ink controller interface.

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Power leakage: save 40mW by turning GSM on

2009-02-22 Thread Joerg Reisenweber

Am So  22. Februar 2009 schrieb Michael 'Mickey' Lauer:
 Am Sonntag, den 22.02.2009, 19:44 +0100 schrieb Rask Ingemann
 Lambertsen:
  But in the end, I realized that the modem powers
  up with deep sleep enabled, so after a few seconds of AT command
  inactivity,
 
 Right, the first thing you should do when working in non-mux mode is to
 %SLEEP=2.
 
 In particular, is it supposed to undo the effects of AT+CFUN=1
  (which
  will turn on receiver, transmitter and everything else needed for full
  GSM functionality)?
 
 Yes. a...@poff is what other modems do when you AT+CFUN=0; actually
 turning off everything.

BTW (on subject) Andy posted a patch today which is stopping burning of 
70mA(!! duh) via high-level uart lines when modem powered down.
Powering down (and up) modem via sysfs node should be fixed and work same time 
now thanks to patch of PaulFerster.
The strange finding of Werner (modem burning more power when actually off than 
in powered up state) should be fixed this way I think.

/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Bluetooth headset routed over USB on Freerunner: why we need it and what problems i faced

2009-02-23 Thread Joerg Reisenweber

Am Di  24. Februar 2009 schrieb Werner Almesberger:
 Paul Fertser wrote:
  Following information is based on AN107 [1] (CSR, 2002, describes SCO
  configuration for BC-01b and BC-02-External) and experience.
 
 Please let me reveal myself as the total BT ignoramus that I am:
 
 Is the bottom line that unidirectional audio (A2DP) over USB to the
 BT device works, but bidirectional audio (SCO) over USB doesn't ?
yup, exactly.

 
 And the reason for this is unknown, but you suspect an audio
 routing issue in the BT module ?
BT has USB interface and PCM interface. Seems there's no way to tell BT to 
accept audio data via USB in SCO (bidir) mode, though there is a way/command 
that *should* work to switch audio input source but doesn't apparently. Might 
be a bug in FW, or poorly or undocumented proprietary command needed.
For A2DP mode (stereo output only) audio data is happily accepted on USB.

Any document about details of actual FW used inside BT module would help a 
lot.
Also asking manufacturer of module rsp chip might be worth a try.

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Bluetooth headset routed over USB on Freerunner: why we need it and what problems i faced

2009-02-23 Thread Joerg Reisenweber

Am Di  24. Februar 2009 schrieb Werner Almesberger:
 Joerg Reisenweber wrote:
  Bet on that? :D
 
 If a tree falls in a forest and no one is around to hear it, does it
 make a sound ? ;-)

Good point.
Anyway sometimes asking might reveal suprising information. Not first time we 
seen important data buried on some laptop or inside some head.

/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: MOKO11b1

2009-02-24 Thread Joerg Reisenweber

Am Di  24. Februar 2009 schrieb Werner Almesberger:
 Dieter Spaar wrote:
  The release version without the b1 is in the SVN at
 
  https://svn.internal.openmoko.org/trunk/calypso/firmware/moko11/
 
 Thanks !
 
  I have kept the long filename in the SVN, feel free to remove or
  rename everything before moko11.m0 when releasing the file.
 
 Perfect :)
 
 - Werner
 

uSD-image pending to be released RSN.
What's status of evaluation now?

/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: MOKO11b1

2009-02-24 Thread Joerg Reisenweber

Am Mi  25. Februar 2009 schrieb Joerg Reisenweber:
 Am Di  24. Februar 2009 schrieb Werner Almesberger:
  Dieter Spaar wrote:
   The release version without the b1 is in the SVN at
  
   https://svn.internal.openmoko.org/trunk/calypso/firmware/moko11/
  
  Thanks !
  
   I have kept the long filename in the SVN, feel free to remove or
   rename everything before moko11.m0 when releasing the file.
  
  Perfect :)
  
  - Werner
  
 
 uSD-image pending to be released RSN.
 What's status of evaluation now?
 
 /j
 

btw: convenience-link: 
http://people.openmoko.org/joerg/calypso_moko_FW/calypso-moko-latest.m0


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Speaker Placement

2009-02-27 Thread Joerg Reisenweber

Am Di  26. August 2008 schrieb Flemming Richter Mikkelsen:
 On 2008-08-19, Esben Stien b...@esben-stien.name wrote:
  It would be nicer if the speakers were placed on top of the device
  instead of at the bottom where they are now.
 
  I have to hold the device kind of awkward to hear the sound coming out
  of it.
 
 I assume the reason is that if any sound should come out from
 those speakers during a call, it is good to have them not too
 close to your ear.

Don't assume actual speaker placement being driven by too much planning and 
thoughts like this.
100% ACK for the covering-by-hand issue - I noticed this early in 2008 and 
mentioned it prior to GTA03 case design, so we may hope for better placement 
on this device ;)

/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM Buzz fix also applicable to GTA01?

2009-03-04 Thread Joerg Reisenweber

Am Mi  4. März 2009 schrieb Tilman Baumann:
 Joerg Reisenweber wrote:
 
 
  So my question is basically if the GTA02 buzz fix works for me and is it 
  reasonable to think that I need it?
  Maybe it can really be fixed with a better alsa state file.
 
  I'll answer more detailed questions on HW-ML (as you can tell from delay I 
  read [community] rather infrequent).
 Oh, good to know. I did not know that hardware topics have a seperate list.
 I have the same problem with the community list. Too much noise, too 
 much unimportant.
 
  Basically the answer is: yes applies to GTA01 as well.
  And no we don't think buzz can be fixed by better statefile neither on 
gta02 
  nor on gta01.
 Does this mean you have a solution for me? Or maybe some upcoming?
 Or only a conformation that it needs to be fixed too?
 -- 
 Imagination is more important than knowledge.
   Albert Einstein
 

basically it's all the same procedure for GTA01. Though you probably don't 
even need to replace a resistor (iirc).
If you really want to do this and can't find your way by using 
GTA01-schematics and component placement on openmoko.com, please ask for more 
help.

/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: USB Mini B Connector

2009-03-11 Thread Joerg Reisenweber

Am Di  10. März 2009 schrieb Sven Klomp:
 Hi,
 
 where I can get a USB cable with a USB Mini B connector on one side with all 
5 
 pins connected? 

https://www.argentdata.com/catalog/product_info.php?products_id=111

Many Thanks to Uwe Klein!

/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: USB Mini B Connector

2009-03-11 Thread Joerg Reisenweber

Am Di  10. März 2009 schrieb Sven Klomp:
 Hi,
 
 where I can get a USB cable with a USB Mini B connector on one side with all 
5 
 pins connected? I need access to the ID pin to add the resistor. A cable 
 called USB Mini A 5pol - USB Mini B 5pol has only four wires. ID is 
 connected to ground as standardised in USB OTG :-(

We are collecting orders for German bulk order.
Feel free to send a mail to jo...@openmoko.org, stating amount you like to 
order.
/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: USB Mini B Connector

2009-03-11 Thread Joerg Reisenweber

Am Mi  11. März 2009 schrieb Sven Klomp:
 And the expensive solution:
 http://www.partsdata.de/USB_Mini-B-Verlaengerung_Kabel_1m_CU-XB05-10.html

Anyway not THAT more expensive, so we won't do any order in USA for Germany.
This one is just fine.

/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Bug #1024 (oscillating re-camping), the story goes on...

I suggest to stop the other 2 32kHz oscillators on mainboard to rule out 
mechanical (as well as electrical / EM) interference between them and the 
calypso oscillator.
Can be done by simply shorting/grounding the crystals, or maybe even with 
config-register settings (not yet checked).
Ping me on freenode #openmoko-cdevel DocScrutinizer if you need help on that.

If there's a clockmaker out there, it would be great to test the one remaining 
32kHz crystal by using the sophisticated acoustical test equipment for wrist 
watches clock.

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Bug #1024 (oscillating re-camping), the story goes on...

Am Mo  30. März 2009 schrieb Werner Almesberger:
 Dieter Spaar wrote:
  Here in my lab environment I can simulate the serving cell
  that is used in the trace. However with my few GTA02 devices
  I don't observe bug #1024 and even in Deep Sleep mode the
  TOA values are stable.
 
 By the way, Joerg has proposed another interesting approach:
 if the oscillator's drive strength is insufficient, we should
 be able to make things worse by reducing it, which you mentioned
 could be done by the firmware.

Dieter, maybe we could have a debug-version of moko11 to implement a service 
AT command to tweak those config registers. This way we could ask users who 
actually can reproduce #1024 to check if there's any difference when issuing 
this power tweaking back and forth.

 
 Is there anything else that's driven by the 32768 Hz clock that
 we can access, e.g., a RTC or some counter ? If yes, we could
 use that to check if the clock has significant variations.

Werner, a brilliant point.

cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Bug #1024 (oscillating re-camping), the story goes on...

Am Mo  30. März 2009 schrieb Dieter Spaar:
 Hello Werner,
 
 Werner Almesberger wrote:
  By the way, Joerg has proposed another interesting approach:
  if the oscillator's drive strength is insufficient, we should
  be able to make things worse by reducing it, which you mentioned
  could be done by the firmware.

 
 Very good idea, I can check that out and see if I get different results.
 
  Is there anything else that's driven by the 32768 Hz clock that
  we can access, e.g., a RTC or some counter ? If yes, we could
  use that to check if the clock has significant variations.

 
 Not something I am aware of. I think the 32kHz oscillator drives a RTC
 if the Calypso chip set alone is used for a simple phone.

Hmm this sounds like there actually *is* sth we can use for this purpose. Is 
it (the RTC) disabled by default on OM's version of FW, or what's the issue 
with it? Or is this RTC an external component that's just clocked by 
calypso's 32kHz. Still it would be interesting to enable such an external 
clock as it maybe would stop the constant disabling/enabling of calypso's 
32kHz clock generator.

/j


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Bug #1024 (oscillating re-camping), the story goes on...