Re: Back to the Basics plan: Andy left
Am Di 24. März 2009 schrieb Laszlo KREKACS: > Who left? > At the hardware side: Werner and Joerg I'm no longer busy for OM on a regular monthly plan. OM is free to contract me for particular tasks, but for now that doesn't seem to happen in the near future. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is "SIM Toolkit" possible to support on the freerunner?
Am Di 24. März 2009 schrieb Michael 'Mickey' Lauer: > Technically, SIM toolkit support is possible with the Calypso. > > I have commented previously about this, so please look my older posts > up; In a nutshell, STK is a heavy cross-layer spec, so adding it would > need quit some thought. > > FSO will not work on it, but appreciate patches. > My vote: don't implement STK, or at least disable it by default. I don't like my SIM to do any "program execution" /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: "Multitouch" on FR ... imho should be possible to mimic
This has been discussed multiple times since last ~15months. The basic assumption a "middle-point" when touching with 2 fingers might be anyway exactly in the middle is incorrect. It depends on pressure of each touchpoint. There have been many different opinions about feasibility of this approach, I for one think it won't work. cheers jOERG Am Do 19. März 2009 schrieb Yaroslav Halchenko: > Hi All, > > I've been cherishing the idea for a while but got no spare time to even > code a proof of concept. so I decided to share it with you so someone > could do that for the common advantage ;) > > Indeed we can't register both touches -- as a result hardware returns > midpoint. BUT what if > > you touch screen with two fingers (at some inter-finger distance like > half of screen width) not at the same time but within > lets say 100-200ms. Ie you "click" with one finger just slightly before > the other one. > > then driver reports 2 coordinates where there is a significant > immediate jump from first coordinate to the midpoint between the two, > which would be as much as 1/2 of distance between the fingers. > > such behavior would signal that 2 fingers are on the screen! > > then if you move 2nd finger somewhere, midpoint would move and that > movement can be taken as a multitouch gesture, ie if you are expanding > 2nd finger away from first one -- it is like 'zoom-out' or increase of > smth. analogously, by comparing to the first coordinate (of 1st finger) > rotations / horizontal zoomin/ vertical zooming etc could be derived > > multitouch gesture mode would stop when fingers leave the screen or > there is once again a singificant jump from prev coordinate (like you > raise one finger up prior to the other one) > > alternative mode can be that after 'two finger' non-synchroneous touch > which switches to "multitouch mode" you drive your gesture with only > second finger (ie raise the first one off the screen) -- that would > allow for better control over the gesture since no averaging of > coordinates between two points would happen. And again, multitouch mode > is left whenever finger is raised of the screen. > > if someone is to implement/test such approach, qwo might be a nice code > base to start from... alternatively I guess tslib for those with > debian+fbdev xserver. > > -- > .-. > =-- /v\ = > Keep in touch// \\ (yoh@|www.)onerussian.com > Yaroslav Halchenko /( )\ ICQ#: 60653192 >Linux User^^-^^[17] > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
Am Mo 23. März 2009 schrieb arne anka: > > You seen Paul's comment about using internal mic in conjunction with > > headphones/headset for GSM purposes? > > yes. > but it has two (and maybe a half) drawbacks > - you need another set of headphones with 2.5 plug Hmm, I don't see the point here. Can be done with any headset/headphones, including the FR accessory ones. Probably I got you wrong. > - someone needs to prepare a state file for that scenario -- i am > incapable to understand that alsa lingo or read the charts NP, I'll supply one. > > the half: what about the sound when you hold the phone so you can use the > stylus or your fingers? will the mic pick up the voice in good quality? Depends on distance mouth->mic. You can test right now. > > will my hand interfere somehow? Same here. Probably not. > the tapping and scartching? Dunno. Good point. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
Am Mo 23. März 2009 schrieb arne anka: > > Yes, this is accurate info. Big-C stopping buzz for internal mic only. > > well, that's pretty disappointing. I agree. Anyway that's as good as it gets. You seen Paul's comment about using internal mic in conjunction with headphones/headset for GSM purposes? /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
As I've been asked to comment by Paul... Yes, this is accurate info. Big-C stopping buzz for internal mic only. Shielding headset may or may not work. There's been reports of stopping or reducing hs-buzz by adding a huge bead next to or inside the hs-plug, to stop RF from entering the device via hs-cable. Anyway this will help to reduce hs-buzz to what it's been for internal mic prior to big-C rework only, as internally "generated" buzz remains the same with buzzfix for MICBIAS voltage to headset (Paul comprehensively explained why) cheers jOERG Am Mo 23. März 2009 schrieb Paul Fertser: > Paul Fertser writes: > > R, soldering two of them in parallel to the same place (already > > s/parallel/series/ signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Am Mi 18. März 2009 schrieb Helge Hafting: > Daniel Willmann wrote: > > On Tue, 10 Mar 2009 15:18:23 +0100 > > Helge Hafting wrote: > [...] > >> It was just to be safe. The documentation states that you might not > >> get a fix _at all_ if either position or time is outside the claimed > >> accuracy. Now, maybe it works with 3km anyway after the fixes that > >> prevents the chip-crashing exception. I happen to live about 6km away > >> from where I work, so 9km was a nice safe value. The default is > >> 300km, and "100km allows a more optimistic startup." Perhaps such > >> rough estimates is all that is needed, if it is only used to figure > >> which satellites that can be seen. > > > > If you don't mind testing please try changing pacc to 100km and see if > > it affects TTFF adversely in your case. If not we could just use that > > as a default. > > Shouldn't be too hard to test. > > I think I know one side of having accurate pacc: > > The first fix can happen with only two satellites. I have seen this > happen several times. It surprised me at first, but it makes sense. With > two satellites (and a reasonable clock), you get a big circle of > possible positions. But then there is the data from the "approximate > position". It puts you at some height above sea level. The big circle > intersects the earth surface at some angle, so with height, we now have > two possible spots instead of a big circle. Usually, only one spot will > be close to the approximate position, so that is where you are. > > That is an "optimistic startup scenario". A too spread out pacc means > both possible spots are within pacc range, and the FR will have to wait > for a third satellite to break the tie. > > If you travel a long way and still report the old position with a fake > precision pacc, then you might be close to the other of the two possible > satellite-based positions. You could then get a fake fix on the wrong > spot. As you and/or the satellites move, the wrong spot will move around > in strange ways at strange speeds. When more satellites show up, the > device might get really confused if it keeps trusting the approximate > position. Perhaps even rejecting them as "reflected signals" for a > while. Of course, only the manufacturer will know the exact details of > what might happen. > > Helge Hafting Wow, I had to read your posting twice to get how brilliant this analysis is. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS emergency call standards
Am Do 12. März 2009 schrieb Harald Welte: > the practical implementation can look quite different. The German government > e.g. now legally mandates that an operator will refuse to take emergency > calls from phones with no SIM card inserted. WTF, those braindead i /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Am So 15. März 2009 schrieb Fernando Martins: > Daniel, many thanks for your replies, please see below. > > Daniel Willmann wrote: > > Hello, > > > > On Thu, 12 Mar 2009 22:19:05 +0100 > > Fernando Martins wrote: > > > > > > there is a backup battery, but in my experience it only takes a couple > > hours without battery until the time is lost again. > > > > > I never leave the battery out, I only take it out to reboot after a crash. > > But now I wonder: usually I keep the phone switched off during the > night, and since I use it rarely, sometimes I forget it switched off at > home. Is it the case that, when FR is switched off, the main battery > does not feed the backup battery? (yeah it sounds weird, the main > battery would become the backup of the backup battery). From PCF50633 PMU datasheet it seems backup bat isn't used as long as main battery is supplying sufficient voltage, no matter whether phone switched off or not. So backup bat is the backup for main bat, not vice versa ;-) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: odd mail, pretends to be from openmoko sales dep
What's the "FROM:" ? /jOERG Am Fr 13. März 2009 schrieb arne anka: > hi, > i just received the mail below -- at a first glance it looks like simple > spam, but on a second one it seems to be from om (and no visible snag). > still strikes me as _very_ odd ... > > had anyone else such experiences? > om: is this legit? and if so, what's the issue with it? > > received mail: > > Dear Sir, > > Thank you for the interest in Openmoko. > Since I have seen you name in the group sales list at the wiki, I was > wondering if you have already received what you intended to buy. If not, > please let me know, so that I can help you processing your order. > > If you have any question, please do not hesitate to let me know. > > Sincerely, > > Ailsa Huang > sales dept. > Openmoko,inc. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [PATCH] Added echo suppression fixes for the OpenMoko Neo phone.
Am Do 12. März 2009 schrieb Al Johnson: > I can see the patch setting %N0187 when making a call, waking, initialising > etc. but not when answering a call. It seems like it needs adding there too to > fix this for some people. AFAIK we never did find out why the echo/nr settings > are persistent for some people and not for others. To me it seems %N should be sent to modem *after* every call, and on modem power-up/reset. After a call is before a call (to quote some famous german soccer saying ;) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTE 4.4.3] Determining which version of GSM firmware I have.
Am Di 10. März 2009 schrieb Friedrich Clausen: > On Tue, Mar 10, 2009 at 11:34 AM, Friedrich Clausen wrote: > > On Tue, Mar 10, 2009 at 11:24 AM, Chris Samuel wrote: > >> On Tuesday 10 March 2009, Friedrich Clausen wrote: > >> > >>> Thanks Florian and Filip for your replies, I will check this shortly. > >> > >> According to the Changelog below the GTA02A5 and GTA02A6 ship with the moko8 > >> firmware, so unless you've flashed it you're going to have that (or earlier if > >> it's an earlier HW rev). > >> > >> http://people.openmoko.org/joerg/calypso_moko_FW/all_version__CHANGELOG.txt > > > > Ah, I am running Moko9-beta1 it seems. I don't see any chance MOKO9b1 is shipped with any of the FR devices. > > I will update to Moko11 when I > > get a chance. > > On the previously mentioned GSM flashing page it says > > > Also PLEASE DON 'T USE moko9beta1, as there is at least one report on reflashing to > > another FW gets difficult from moko9b1. Nevermind this comment. Flashing GSM-FW back and forth never failed on a single case we seen so far, for all versions from MOKO8 to MOKO11 /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flashing GSM firmware
Am Mo 9. März 2009 schrieb Rask Ingemann Lambertsen: > On Thu, Mar 05, 2009 at 10:25:40AM +0300, Paul Fertser wrote: > > > > All this steps except starting fluid.exe are not strictly necessary > > and i'd recommend to start fluid like that: > > > > FLUID_PORT=/dev/ttySAC0 fluid.exe -oo -od13,13 -f > > > > Notice i use ROM bootloader and moko11 firmware. > >I flashed the moko11 GSM firmware today and found the same thing: -oo > without FLUID_FLOWCONTROL works. option -oo is recommended standard operating procedure for now. There's no particular advantage in trying to use firmware-bootloader first. > I couldn't not get any of the other > combinations to work. Others did. > I first backed up the old firmware, then flashed the > new one: > > # time FLUID_PORT=/dev/ttySAC0 fluid.exe -oo -r 0x..0x0040 -f ~rask/download/firmware/calypso-firmware-backup.m0 > (real 6m28.286s user0m11.200s sys 0m4.315s) > > # time FLUID_PORT=/dev/ttySAC0 fluid.exe -oo -f ~rask/download/firmware/calypso-moko11.m0 > (real 2m56.764s user0m16.070s sys 0m0.990s) > >I did need two power off/on cycles between the two fluid invocations, > though. I did not use "s3c24xx-gpio b7=0" as according to the schematics, > pin GPIOB7 is just the MODEM_ON signal. This doesn't exactly explain anything. For relation of SoC GPIO-b7 and and PMU GPIO2 see discussion of gsm sysfs node fix in [hw]. If you were lucky to successfully flash without using "s3c24xx-gpio b7=0" you probably used a recent kernel with sysfs node fix. Anyway not following the quite accurate and detailed instructions on gsm/flashing might explain why you didn't see any success on "the other combinations" /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Pulster fixe(s) and rework
http://wiki.openmoko.org/wiki/GTA02_bass_fix /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM Power off
Am Mi 25. Februar 2009 schrieb Helge Hafting: > Paul Fertser wrote: > > Michael 'Mickey' Lauer writes: > - echo "a...@poff" >/dev/ttySAC0 > >>> This is supposed to ask modem firmware to power off itself. Was > >>> necessary because GTA01 has no physical power switch. I don't know > >>> exact results of this command though. > >> IIRC it issues a controlled shutdown including deregistration from the > >> network and shutting down RF. > > > > But is it really necessary? One can as well suddenly go out of > > coverage without any deregistrations. Does it really matter for the > > network? > > It guess it might matter for the network - if a call comes in. > If you told the network about powering off, they will notify the caller > immediately that your phone is not available. > > If you powered off abruptly and the network haven't timed your phone out > yet, then the tower will try its best to reach you while the caller > waits. Some callers may guess (incorrectly) that you are ignoring their > call. correct /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flashing GSM firmware
Am Do 5. März 2009 schrieb Andy Green: > Somebody in the thread at some point said: > | On Thu, 5 Mar 2009, Paul Fertser wrote: > | > |> Alternatively, try Joerg's uSD automated image: > |> > http://people.openmoko.org/joerg/calypso_moko_FW/moko11/flash-moko11_uSD-image.tar.gz > |> > |> It works and reliably flashes the firmware for you. > | > | yaaay joerg and thank you! i just safely and efficiently upgraded > both my > > I think there's a little confusion going on here, AIUI Werner did the > rootfs end and Deiter the GSM firmware upgrade and deserve the thanks > for that. You haven't understood it quite right, and obviously there *is* some confusion going on *somewhere*. rootfs is a standard FSO-console MS5 patched to fix "doesn't boot on r/o mounted fs" issue. Kernel is recent Andy tracking with GSM sysfs node patch created originally by PaulFerster based on my suggestions. MOKO11 was a corporate work involving quite a number of people on IRC, mainly PaulFerster, Werner, Lindi (iirc), and me. Dieter checked for the bugs we spotted and fixed them in calypso's FW. The uSD image was entirely created, tested and published by me. Original idea: roh. So all those people deserve a special "thank you", and Andy deserves a special acknowledge for sedulous mobbing as soon as "joerg" is mentioned somewhere. >:( /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Pulster fixe(s) and rework
Am Mi 4. März 2009 schrieb Fox Mulder: > Johny Tenfinger wrote: > > On Wed, Mar 4, 2009 at 08:32, Joerg Reisenweber wrote: > >>> * Change the led transistor power hungry stuff > >> Guys, this has been fixed for *ALL* FR ever sold!!! > > > > No, no, no. You are right only for GTA02v6. On GTA02v5 (which I have) > > this has been fixed only for orange and blue LEDs under POWER button. > > Red AUX button is still power hungry - it is eating 50mA. > > Your mentioned 50mA for the AUX LED is ridiculous. It would burn out > with this high current. Normal LEDs only use ~20mA and low current LEDs > ~2mA. 50mA would be for a higher power led which isn't build into the > freerunner. > And when you are on battery the AUX led is off by default and even if it > blinks (like i modified my led behaviour) it isn't really much it uses. > > Ciao, > Rainer The power is consumed by driving a common-emitter transistor driver for LED without base resistor. Current flows from GPIO via base to emitter, and it for sure had been wiser to drive LED directly from GPIO ;-), instead of burning 40mA base current for 10mA collector current. (ballpark numbers) For the non-fixed AUX LED: I wasn't aware these versions have been sold :-/ cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Pulster fixe(s) and rework
Am Mi 4. März 2009 schrieb Helge Hafting: > Joerg Reisenweber wrote: > > Am So 11. Januar 2009 schrieb Alexandre Ghisoli: > >> Le Sun, 11 Jan 2009 19:07:40 +0100, > >> Konstantin a écrit : > >> > >>> Matthias Apitz schrieb: > >>>> Hello Christoph, > >>>> > >>>> Could you please also make an offer for the hardware buzz fix in DE: > >>>> http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP_rc2.pdf > >>>> Would be great! > >>>> > >>>> Thx > >>>> > >>>> matthias (one of your happy GTA02 customers) > >>> I second this one - offering the hardware fix for the freerunner > >>> would be great :) > >>> > >>> Regards, > >>> Konstantin (One of your other happy GTA02 customers ;) ) > >> Yes, hardware fixes (rework) made by resellers would be great. > >> > >> By fixes, I mean : > >> > >> * GPS - SDIO fix (add a capacitor if I remember correctly) > > There's a sw-fix for that, which mostly "just works" > > > >> * Add a GSM IR resistor for deep sleep > > Huh? > > > >> * Change the led transistor power hungry stuff > > Guys, this has been fixed for *ALL* FR ever sold!!! > > > >> * fix the GSM buzz > > ok, agree here. > > > > If I ship the phone somewhere to have a technician fix the buzz, I > definitely want the "small capacitors on headset output" issue fixed too. > > The capacitor, combined with the resistance of earphones, form a > high-pass filter. > > The cutoff frequency is 1/(2*pi*R*C), where R is headphone resistance > and C is the size of the capacitor. The capacitor in the FR has been > reported as 1 microfarad. My headset is about 40 ohm, which gives a > cutoff frequency of about 4kHz. > > At 4kHz the sound is halved, and drops by 6db per octave below that. > Above, the sound is almost normal. Unfortunately, most of the sound we > hear is below 4kHz. > > A headset usually works down to about 20HZ. If I want the cutoff > frequency there, a 200 microfarad capacitor is needed. > > Is there a plan for such a fix as well? > > Helge Hafting Hey, you copied my mail from ~1year ago ;-) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM Buzz fix also applicable to GTA01?
Am Mi 4. März 2009 schrieb Tilman Baumann: > I have the feeling my GTA01 would also need the buzz fix. > Especially in high antenna power situations I have quite substantial > buzzing. > That might be new, since I have never seen this before, but I only > lately started to use my GTA01 as my main phone, I was more of a land > line type before. > > 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. > > GTA02 and GTA01 seem to differ quite substantially in regard to board > layout, but I guess the audio schematic does not so much. > > -- > Imagination is more important than knowledge. I'll answer more detailed questions on HW-ML (as you can tell from delay I read [community] rather infrequent). 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. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Pulster fixe(s) and rework (was: Re: buzz fix)
Am So 11. Januar 2009 schrieb Alexandre Ghisoli: > Le Sun, 11 Jan 2009 19:07:40 +0100, > Konstantin a écrit : > > > Matthias Apitz schrieb: > > > > > > Hello Christoph, > > > > > > Could you please also make an offer for the hardware buzz fix in DE: > > > http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP_rc2.pdf > > > Would be great! > > > > > > Thx > > > > > > matthias (one of your happy GTA02 customers) > > > > I second this one - offering the hardware fix for the freerunner > > would be great :) > > > > Regards, > > Konstantin (One of your other happy GTA02 customers ;) ) > > Yes, hardware fixes (rework) made by resellers would be great. > > By fixes, I mean : > > * GPS - SDIO fix (add a capacitor if I remember correctly) There's a sw-fix for that, which mostly "just works" > * Add a GSM IR resistor for deep sleep Huh? > * Change the led transistor power hungry stuff Guys, this has been fixed for *ALL* FR ever sold!!! > * fix the GSM buzz ok, agree here. > * ... ??? /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: buzz fix
Am Di 27. Januar 2009 schrieb Paul Fertser: > > Al Johnson writes: > > On Monday 26 January 2009, Christoph Siegenthaler wrote: > >> are there any updates from resellers, FIC or any half-official > >> DIY-tutorials on the hardware problems, i.e. the buzzing? > > > > This appears to have benefited from feedback regarding capacitor types from > > the few people so far to have attempted the mod, > > The feedback is that: you can use any cap, including tantalum. :) > > > but more feedback is requested. The lack of feedback from people > > trying it may be why it hasn't yet made it past release candidate > > stage. > > No more feedback is really needed. Everyone who performed the rework > confirmed that it eliminates the buzz. No single negative report. And > i guess at least 10-20 people have already tried the rework. So, the > reason that no reseller is doing it yet is probably due to > communication/business issues rather than technical. Exactly. I'm not in charge any more to push this fix, but to me it seems we really don't need to quantify "how much it improves" buzz-issue. The cause and ways to creep in of buzz are well understood by now by some guys at least (and NO it's NOT the mic catching RF near antenna, it's pin4 of hs-jack), the bigC-rework is evidently (based on empiric and EE basics) eliminating the ripple we see on MICBIAS, and a gsmhandset.state file correctly using differential input mode (control.63 value "Mic 2") won't break audio function from unfixed to buzzfixed FR. Also we don't need any sophisticated test procedure, as * all devices are prone to buzz issue, so we don't need to prove there is buzz before fix * the big-C rework will either kill the buzz or you find you did sth wrong and mic stops to work. So any engineer doing the actual fix doesn't need any sophisticated "fix succeeded" test more complicated than that involved in replacing a lightbulb. Test call -> works -> fine. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Crackly Calls and Battery Tips! A5/A6 rework. Corrected URL
Am Mi 17. Dezember 2008 schrieb Esben Stien: > Steve Mosher writes: > > > If guys raise there hand to help others out I'll come up with a > > program to help them out/ reward them. If you are willing to raise > > your hand, drop me a mail. > > I've talked to a local electronics repair shop here in Bergen, Norway > and they said they will do this operation. There, however, should be a > package which contain all relevant documentation and complete > circuitry and dismantling the freerunner to help a technician easily > and quickly do this operation and not waste time finding the > documents. ok, I'll rework SOP another time to meet these needs. for now lease refer to wiki about opening he case, and search my people/ folder for recent document (rc2 atm). /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to remove microSD card
Yeah, and manufacturer of the component doesn't even pay royalties while still using it on his newest bunch of card-fixtures ;-) http://people.openmoko.org/joerg/sdcard-handle/ /j Am Do 4. Dezember 2008 schrieb Steve Mosher: > I think joerg patented that. > > Marco Trevisan (Treviño) wrote: > > Franky Van Liedekerke wrote: > >> Ok, so I'm feeling totally moronic now ... I'm pretty sure I entered my > >> microSD card some 3 months ago, but I can't seem to figure out how to > >> remove it again ... some howto for a gta02? I can't seem to find any > >> lever or pressure thingie to get it to pop open there and the info > >> mentioned on > > > > What about using a piece of scotch tape to pull the metal? > > > signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian -FSO -GPS] No Fix
Am Sa 29. November 2008 schrieb arne anka: > > Either the GPS knows where to look for the sats (due to accurate data > > being supplied by AGPS) > > true, o pharao -- but afair the issue was, that no fix at all was obtained. > and if that is caused by whatever feeds the ublox with agps data, the > feeding routine has to be more tolerant, ie issue a fallback to scanning > instead of solely relying on agps. AGPS is *not* disabling normal non-"A" operation of GPS (means there is no need for a paricular fallback scheme - GPS starts and operates in "fallback-mode" all the time, "A" just updates a few variables more quickly than the GPS-chip would do anyway, so the chip finds his channels/sats/fix. Even if we would write completely bogus info to the chip, it wouldn't be worse off than without AGPS and starting on default values. btw: It seems to me as if 3 minutes difference in time shouldn't make any trouble. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian -FSO -GPS] No Fix
Am Do 27. November 2008 schrieb arne anka: > > I don know why, and I'm not shure if it was solved by the changes I have > > made, but after time and timezone was correct fso-gpsd fixed in less then > > 2min. > > if that's really the cause it needs fixing -- my fr is always about 3 min > behind in time when rebooted and i do not always have a ntp source > available to sync. > wasn't there recently something about fso feeding the u-blox data on > startup and that the data needs to match time and so on? then this routine > needs to be more tolerant. Feeding GPS with correct data about recent sat positions isn't something you can make "more tolerant". Either the GPS knows where to look for the sats (due to accurate data being supplied by AGPS), or it needs to scan all possibilities to find where to get an actual signal (which may take quite a while). cheers jOERG [["position" and "where" used herein as a synonym for frequency/channel. Though the position in space also needs to be known to calculate exact GPS-data]] signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
PLEASE DON'T ANSWER THIS THREAD - Re: Freerunner's GSM Calypso Modem Firmware Upgrade...
May I request everybody answering to this topic please switch to the original thread on [devel]-mailinglist[1], so we can keep all the stuff ongoing regarding success / problems with flashing GSM-FW at one place. Many thanks for kindly regarding this. cheers jOERG Am Mi 19. November 2008 schrieb Marco Trevisan (Treviño): > This is just to notify the community users who don't read the devel > list: Joerg, Dieter and Werner set up some tools to upgrade the firmware > of the GSM Modem of the Frerunner (TI Calypso) to a newer image [1]. > > If you're affected by the infamous #666 - No SIM found - bug, you could > try to upgrade your phone's firmware using the tools provided by OM guys > to the moko10 (beta2) version [2]. > > Look at the wiki [3] for more help and keep us (and the Devs) informed! > > [1] http://n2.nabble.com/Calypso-firmware-update-tp1503771p1513061.html > [2] They're closed, but it's not an OM fault, and I think we should > thank them for this too. > [3] http://wiki.openmoko.org/wiki/GSM/Flashing > > -- > Treviño's World - Life and Linux > http://www.3v1n0.net/ > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner's GSM Calypso Modem Firmware Upgrade...
Please could you switch to original thread on [devel]-ML. /j Am Di 25. November 2008 schrieb Lally Singh: > Seemingly no luck here. > > T-Mobile SIM, I suppose 3G. > > Still says sim missing. > > -ls > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Expressing hope that the next-gen Openmoko hardware might support 3G/3.5G/HSDPA when it arrives
Am Mo 24. November 2008 schrieb W.Kenworthy: > Are there any statistics available on how many phones have been sold and > where - I ask out of interest, but realise this may be something thats > is commercially sensitive so wont be released. > > BillK Yes, exactly ;-) cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Will there be a hardware revision for the buzzing issue?
Am Mo 24. November 2008 schrieb hiciu: > Is buzzing issue linked with speaker? > > When my freerunner has removed case and I'm calling to someone I can > hear silent buzzing. But I am sure it comes from back of the phone > (near GPS antenna), not from speaker. It is really silent and I can > hardly hear it with case putted on. It is there even if I use headset > or mute speaker in alsamixer. It isn't issue for me, but I wonder if > it is related to "this" buzzing issue or it's something completely > different. > > Sorry for my bad English. I hope you can understand what I'm mean :). This is probably caused y the high intermittent current the GSM-modem is drawing from battery, what makes coils and the ceramic capacitors on the current path act like little speakers. No reason to be scared ;-) /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [any] charging FreeRunner from Minty Boost
Am So 23. November 2008 schrieb Matthias Apitz: > > Hello, > > Today I've done some tests charging my FR from the Minty Boost: > > - the two AA batteries are: 2700mAh NiMH 1.2V from Varta, they have been > fully charged and directly pulled out of the Varta charger; > > - I've been waiting until battery.py showed the FR with 10% of left > capacity; > > - plugged in the Minty Boost and switched it to 500mA mode; this is the > position X in time in the small table below; > > - I watched every 30 minutes the charging process; the FR was signed in > into cellphone network, display mainly switched off and only > 'battery.py' was running; this gives > > X + 00min -- 10% (time to full 4.5h) > X + 30min -- 24% > X + 60min -- 39% > X + 90min -- 53% > X + 120min -- 62% > > then in stopped charging, maybe because the AA batteries have been > to low; have no item to measure them :-( > > Any comments; > > matthias 500mA * 120min = 1000mAh * 5V (USB) = 5Wh 1.2V * 2 * 2700mAh =6.48Wh considering efficiency of voltage converter all this looks about right cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Minty Boost && FreeRunner
Am Fr 21. November 2008 schrieb Tobias Diedrich: > Cédric Berger wrote: > > On Thu, Nov 20, 2008 at 17:24, DJDAS <[EMAIL PROTECTED]> wrote: > > > Cédric Berger ha scritto: > > >> I did not have a look at neo's circuitry. > > >> But whatever the method it uses, it cannot force 1A if 1A is not > > >> available (wall charger unplugged from the wall won't give 1A :-p ) ? > > >> > > > Uhm...not exactly true... Ohm Law says: V = R * I -> I = V/R, and if > > > R->0 then I->oo > > > In practice if you power a load with a little impedance (in real systems > > > the load is not always only resistive) the current requested will grow > > > and the source could be damaged (try to short circuit a normal battery, > > > you'll see a flash and if you maintain the circuit closed you'll meld > > > the battery). > > > This is why you should not ask 1000mA from the USB port (for example) > > > unless you're sure the hardware could give it. > > > Bye :) > > > > > > > Yes but I also have some car adapters that "did not mind" being > > shorted (12v to 5v adapter, given for 350mA). So I doubt a device > > wanting 1A would be worst than a short circuit... but what would be > > the output in such a case I do not know. > > According to the MAX756 datasheet (the step-up converter used in the > minty boost AFAICS), the switching mosfet should be protected due to > the operating principle: > The coil is shorted to ground until the current reaches about 1A, > then switched off automatically (and then the coil discharges in > series to the battery, effectively boosting the voltages). > > So the only things relevant to a overload situation are the > coil rating and the diode rating. > If both are capable of handling >1A continously, then switching > the Freerunner to 1A can't break anything. > The 1N5818 can handle 1A and the coil used has a saturation current > of 1.5A. > > (However, it is _not_ short-circuit-proof, since in that case the > current would flow directly from the battery over coil and diode to > ground and will likely destroy the diode first) > > Switching noise is nothing to worry about (Switching frequency depends > on load and battery voltage). > > Of course thermal dissipation can still be an issue. you should use a polyfuse, to make device resistant against short on output /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Will there be a hardware revision for the buzzing issue?
Am Do 20. November 2008 schrieb robert lazarski: > On Thu, Nov 20, 2008 at 6:07 AM, robert lazarski > <[EMAIL PROTECTED]> wrote: > > On Thu, Nov 20, 2008 at 3:00 AM, Joerg Reisenweber <[EMAIL PROTECTED]> wrote: > >> Am Mo 17. November 2008 schrieb robert lazarski: > >>> Hi all, > >>> > >>> I'm about to buy an openmoko, as I finally have some time and cash. > >>> However, my understanding is that the latest phones for sale have a > >>> buzzing issue and its confirmed to be hardware related. Will there be > >>> a hardware revision? Or I'm a stuck using a soldering iron and new > >>> parts to fix it? Please correct me if I'm misinformed. > >> > >> We are actually in the process to figure out how to fix *all* devices sold, by > >> implementing the so-called "big-C" fix (which means add a 100uF, replace one > >> R), which can be done by those experienced in soldering. Not yet clear where > >> this will end, but we're on it. > >> > >> Very next thing is we will publish a rework SOP paper. > >> > >> Also see other answer in this thread. > >> > >> cheers > >> jOERG > >> > > > > Thanks for the info. While I'm good at soldering, I'd prefer to wait > > for an "A7" revision if that happens. Searching the hardware archives > > mentioned there might be one: > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00696.html > > > > I realize it may take a while. I'm guessing A7, if it happens, may > > also have other updates which may help some other issues of the phone. > > Looking at the hardware wiki, I see no list of confirmed or even > > suspected hardware issues. My interest in openmoko is kernel and > > bootloader related, and there's just somethings that can't be fixed in > > hardware despite the steady stream of patches I see on the kernel > > list. So I'm unclear if some issues like suspend, battery life amd > > missed calls are perhaps hardware issues? Just trying to make an > > informed choice between buying now or later. > > > > Best regards, > > Robert > > > > s/can't be fixed in hardware/can't be fixed in software/ > > - R > for A7 there's no bugfix changes to expect, except beforementioned big-C rework for buzz issue. There are some minor improvements on audio quality for headset stereo (1u->4.7u). That's no bugfix in the end :-/ Currently we are not planing any hw-fixes for known bugs, that didn't make it to A7 version, means we aren't aware of such bugs that could be fixed for A8. For an eventual A8 we are planning some minor layout changes (3 beads) to make even more sure buzz is gone. (maybe this might also improve situation of buzz while using wired headset for a call. However it's not aimed at that topic) All A5 and A6 versions can be updated to A7 version by cumulative application of the changes done from A5 -> A6 -> A7 (again that's nothing more than big-C for recent A6) All this to the best of my knowledge, without any warranty ;-) HTH cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Will there be a hardware revision for the buzzing issue?
Am Mo 17. November 2008 schrieb robert lazarski: > Hi all, > > I'm about to buy an openmoko, as I finally have some time and cash. > However, my understanding is that the latest phones for sale have a > buzzing issue and its confirmed to be hardware related. Will there be > a hardware revision? Or I'm a stuck using a soldering iron and new > parts to fix it? Please correct me if I'm misinformed. We are actually in the process to figure out how to fix *all* devices sold, by implementing the so-called "big-C" fix (which means add a 100uF, replace one R), which can be done by those experienced in soldering. Not yet clear where this will end, but we're on it. Very next thing is we will publish a rework SOP paper. Also see other answer in this thread. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ANNOUNCE] Neo1973 DebugBoard v2 Schematics released
Am Mi 19. November 2008 schrieb Vladimir Koutny: > > I short search on our documentation server revealed this: > > http://people.openmoko.org/joerg/schematics/debug_board/OpenMoKo_Debug_Board_V3_MP.pdf > > Oh, nice.. > > May I ask for one more thing - permissions? ;) > > Forbidden > You don't have permission to > access /joerg/schematics/debug_board/OpenMoKo_Debug_Board_V3_MP.pdf on this > server. ooops, sorry ~~ fixed /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ANNOUNCE] Neo1973 DebugBoard v2 Schematics released
Am Mi 19. November 2008 schrieb Vladimir Koutny: > Hi Harald, > > > Today I can proudly announce that we finally were able to take a step > > that has long been anticipated: The public release of the schematics > > for our Debug Board v2. > ... > > Oh, and yes, as soon as we start shipping DebugBoard v3, we will release > > those schematics without any further delay. > > Is there any progress in this area? :) > > What I'm looking for just now is the pinout for the new i2c/spi/irq header > included on v3 debug boards - but can't find it (nor the schematics for v3). I short search on our documentation server revealed this: http://people.openmoko.org/joerg/schematics/debug_board/OpenMoKo_Debug_Board_V3_MP.pdf Not checked yet for correctness of schematics, or if this even is what the name suggests. Anyway HTH ;-) cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Nokia BL-5C replacement battery
If you bought a Nokia BL-5C for a spare battery, you might want to check this site: http://batteryreplacement.nokia.com/batteryreplacement/en/ cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Car charger to GTA02
Am Fr 8. August 2008 schrieb Michael: > On 11/07/08 00:00:51, Marco Trevisan (Treviño) wrote: > > > I'm pretty sure the neo1973 cant charge with more than 500mA due to > > > the hardware, nothing in software will fix that, I think the post > > you > > > quoted was about the freerunner. > > > > I read months ago that it should be able to charge at 1000mA too (if > > charger supports it). > Just to clear this up, I have read through the kernel source for the > GTA01 pmu driver and there is no mention of 1000mA, but there is in the > GTA02 driver. So either the PMU does not support it, or the kernel does > not use this fature in its driver. > > Michael. IIRC, PCF50606 can't do 1000mA, only PCF50633 can. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sean: Please authorise the release of GTA01 schematics
Sorry, I don't understand exactly what you're complaining about? /jOERG Am Fr 8. August 2008 schrieb Joshua Broussard: > Suggest you pull the GTA01 and properly strip out the material > protected by NDA. I can see it in part by highlighting all text on > page. > > R/ Josh > > On Thu, Aug 7, 2008 at 2:38 PM, Joerg Reisenweber <[EMAIL PROTECTED]> wrote: > > Am Sa 2. August 2008 schrieb Joerg Reisenweber: > >> Am So 20. Juli 2008 schrieb Rod Whitby: > >> > Sean, please release the hardware schematics and pcb layout and > >> > component placements for the GTA01. > >> > > >> > Let the GTA01 run free and continue to impact the material world. > >> > > >> > Respectfully, > >> > -- Rod Whitby > >> > >> > >> PCB-layout is a little difficult to release - this is a multilayer PCB. > >> Component placement 01/02 TBD. > >> Schematics 01 TBD. > >> Needs some prettyprinting first. Also there are NDA-issues with TI Calypso. > >> Those parts of schematics we mustn't release you may find elsewhere though > >> (heard sth about Chinese books on cellphones ;) > >> > >> Stay assured we won't forget on GTA01 owners. > >> cheers > >> jOERG > >> > > > > added GTA01, component-placement for 01 and 02 > > see > > http://people.openmoko.org/joerg > > and > > http://downloads.openmoko.org/schematics/ > > > > for some echo in press see > > http://www.google.de/search?q=openmoko+schematics > > > > please note this is a RC, not a "gold" > > Feel free to comment! > > > > cheers > > jOERG > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sean: Please authorise the release of GTA01 schematics
Am Sa 2. August 2008 schrieb Joerg Reisenweber: > Am So 20. Juli 2008 schrieb Rod Whitby: > > Sean, please release the hardware schematics and pcb layout and > > component placements for the GTA01. > > > > Let the GTA01 run free and continue to impact the material world. > > > > Respectfully, > > -- Rod Whitby > > > PCB-layout is a little difficult to release - this is a multilayer PCB. > Component placement 01/02 TBD. > Schematics 01 TBD. > Needs some prettyprinting first. Also there are NDA-issues with TI Calypso. > Those parts of schematics we mustn't release you may find elsewhere though > (heard sth about Chinese books on cellphones ;) > > Stay assured we won't forget on GTA01 owners. > cheers > jOERG > added GTA01, component-placement for 01 and 02 see http://people.openmoko.org/joerg and http://downloads.openmoko.org/schematics/ for some echo in press see http://www.google.de/search?q=openmoko+schematics please note this is a RC, not a "gold" Feel free to comment! cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
THREAD MOVED! any update on GSM interference issue
moved thread to [hardware]-ml, please continue there. This thread closed and discontinued. thanks jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: any update on GSM interference issue
Am Mi 6. August 2008 schrieb Al Johnson: > On Tuesday 05 August 2008, arne anka wrote: > > > The ferrite is increasing the common mode inductance of the cable > > > because the > > > ferrite has a better magnetic permeability than air. Taping the ferrite > > > to > > > the cable is a bit like a half turn on a ferrite rod. It will still > > > affect > > > the inductance, but not as much as if it went through a ferrite ring. > > > > anything to pay attention to in particular (size, color, taste or smell > > ;-) or just using one that fits? > > Given the less-than-scientific application, probably just one that fits ;-) My > electronics experience doesn't go beyond audio frequencies though, so don't > believe a word I say once it involves RF! Use one that fits. there should be those beds with a plastic fixture around and two "half-rings" inside, that can easily be opened, cable placed inside, and then close the two halves and a plastic nose will snap in and hold the whole thing. PLEASE NOTE: I'm going to move this thread to [hardware]-ml and join it with another thread of same topic from [support], in a few hours. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firmware Re: IMEI
Am So 3. August 2008 schrieb Mikko Rauhala: > su, 2008-08-03 kello 04:12 -0700, Learning It kirjoitti: > > Do we have sources of firmware for GSM chipset? > > No. Actually OM *has*, but they are under heavy NDA. Probably this also is the reason we must not provide FW-updates for users. Even the binary might open a path to change IMEI or reverse engineer other details of Calypso. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: USB connector not Mini-AB?
Please can someone create a wikipage out of this valuable collection of links!? Also include Andy's msg some posts up the thread! Am Di 29. Juli 2008 schrieb Charles Pax: > On Mon, Jul 28, 2008 at 9:07 AM, Al Johnson > <[EMAIL PROTECTED]>wrote: > > > On Monday 28 July 2008, Andy Green wrote: > > > > > > It does not mention mini-AB there, it only mentions micro-AB, so now I > > > know even less than I did when I started :-) > > > > Looks like mini-ab and mini-a were deprecated over a year ago in favour of > > the > > micro varieties. I've never seen a micro-usb connector! > > http://www.usb.org/developers/Deprecation_Announcement_052507.pdf > > > > Here is a picture comparing mini USB (looks like the USB-B variety) on the > left and the new micro-USB (a, b, or ab?)on the right. > http://www.intomobile.com//images/2007/05/27/motorola_razr2_v8img_3995.jpg > > What is micro-USB? > http://www.tech-faq.com/micro-usb.shtml > > Some articles on mobile phone manufacturers switching: > http://www.berryreview.com/2008/07/11/javelin-sports-micro-usb-jack-instead-of-current-mini-usb/ > http://gadgets.boingboing.net/2007/09/21/phone-manufacturers.html > http://news.cnet.com/Pros-seem-to-outdo-cons-in-new-phone-charger-standard/2100-1041_3-6209247.html > http://edageek.com/2007/01/04/usb-if-micro-usb/ > http://www.eetasia.com/ART_8800475645_590626_NP_a34a00de.HTM > http://www.engadget.com/2007/01/05/mobile-phones-to-adopt-smaller-micro-usb-connector/ > http://www.everythingusb.com/nokia_8600_luna_13128.html > http://www.mobileburn.com/pressrelease.jsp?Id=2992 > http://blogs.techrepublic.com.com/tech-news/?p=1238 > http://www.theunwired.net/?item=standardization-omtp-recommends-micro-usb-as-the-standard-for-mobile-phones > http://news.zdnet.co.uk/communications/0,100085,39289524,00.htm > > Adapters: > http://www.wireless.att.com/cell-phone-service/accessory-details/?q_categoryid=cat1370029&q_sku=sku1070095 > http://www.daydeal.com/product.php?productid=22483&cat=3454 > http://www.shopalltel.com/product/product.htm?prId=33455 > http://www.walmart.com/catalog/product.do?product_id=9446449 > > Chargers: > http://plantronics.com/north_america/en_US/products/mobile/mobile-headset-accessories/car-charger-micro-usb-corded > > Manufacturers of micro-USB connectors: > http://www.hirose.com/news/news7.htm > http://www.molex.com/cmc_upload/0/000/417/929/microusb_pr.html > > Any information on when the Freerunner will make the switch to micro-USB? > The deprecation announcement above makes this seems imminent. Freerunner won't change, it's been developed prior to this ECN/deprecation note (at least true for the housing, a heritage from GTA01, which isn't easy to change for new connector) cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM Stuff
Am Sa 2. August 2008 schrieb Scott: > I got the GSM external antenna adapter from DigiKey > > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=490-4982-ND > > Fits perfectly in the phone, Would I recommend crap to you? ;-) Anyway please note this is a test-adapter not designed for rough trade every day use. Also the receptacle on phone is designed for 500 rounds of insert/plug. There were no tests done on what will break after those 500 plug-actions. Might be the adapter doesn't click in anymore, may also turn out it's the switch that fails to connect to *internal* antenna when no jack plugged. Be warned! > had to order an adapter though as the > other end is an SMA-J female and I needed to connect to a TNC male. > > Also got the caps for the SD card rework, Jesus are they tiny! I'm > gonna get out my magnifying glass For sure you need > and set one up to evaluate if I think > I can solder that "grain of sand" sized unit or not! Honestly, I've seen grains of sand much bigger than this, no shit! > I guess its sized > so it won't interfere with the card. Still you need take care not to scratch that grain of sand off the device when opening the card-holder. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sean: Please authorise the release of GTA01 schematics
Am So 20. Juli 2008 schrieb Rod Whitby: > Sean, > > Now that the FreeRunner is selling like hotcakes, and your hardware and > software teams must focus on it to ensure that it succeeds in the > market, and the GTA01 Neo1973 is no longer in production or being sold > by Openmoko or its distributors, surely it's the perfect time to release > the GTA01 hardware schematics? > > This would send a clear message to the community and the whole mobile > ecosystem that Openmoko is a company that doesn't leave it's customers > in the lurch when it brings out a replacement product like closed > ecosystem companies do, but that Openmoko is a company that wants it's > customers to continue to impact the material world with *all* of it's > products - past, present and future - for many years into the future. > > Allow the amateurs to continue to have the distinct advantage over the > professionals even years after the professionals have moved onto the > next piece of hardware. Imagine a world where new uses for 10 year old > Openmoko hardware are still being found, because the schematics for > previous generation products are always released when Openmoko ceases to > produce or sell that product. Imagine how much wider the impact of > Openmoko can be if older products are not thrown in the bin due to lack > of information availabe to repair them, but are instead repaired by > people in the community or amateur ecosystem and then put back into > service to continue to spread the word about the clear advantage that > open source has over the closed ecosystem. > > Sean, please release the hardware schematics and pcb layout and > component placements for the GTA01. > > Let the GTA01 run free and continue to impact the material world. > > Respectfully, > -- Rod Whitby PCB-layout is a little difficult to release - this is a multilayer PCB. Component placement 01/02 TBD. Schematics 01 TBD. Needs some prettyprinting first. Also there are NDA-issues with TI Calypso. Those parts of schematics we mustn't release you may find elsewhere though (heard sth about Chinese books on cellphones ;) Stay assured we won't forget on GTA01 owners. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sean: Please authorise the release of GTA01 schematics
Am So 20. Juli 2008 schrieb Charles Pax: > On Sat, Jul 19, 2008 at 11:24 PM, steve <[EMAIL PROTECTED]> wrote: > > > He asked for GTA01. WE are giving GTA02. > > > > I look forward to printing them out and rolling around on them. > > -Charles > keep your video camera steady, Charles! (btw: use A3-format!) We *really* want to see this next week ;-) Maybe you can use the 2 days of this weekend? cheers jOERG :-) signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
SDcard holder - convenience "rework"
for a nice handle to save your fingernails and do no violence on SD-holder by using a knife etc, see: http://people.openmoko.org/joerg/sdcard-handle note the pretty original scotchtape-end of the transparent sticky tape ;-) Works like a charm! cheers jOERG ps: thanks to XorA for triggering the idea by complaining about the "varnish-killer" ;-) signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: external GSM antenna
Am Do 31. Juli 2008 schrieb Dale Schumacher: > On Wed, Jul 30, 2008 at 1:11 PM, Joerg Reisenweber <[EMAIL PROTECTED]> wrote: > > The GSM-connector to be found near one of the screws (see [disassembling Neo > > 1973] in wiki) is: > > MURATA MM8430-2610RB3 SMD RF TEST PORT > > > > For a nice fitting adapter see attached photo and: > > http://www.google.de/search?q=MXHS83QE3000 > > Just to avoid (more) confusion. The photo called "gps-adapter.jpg" is > actually a GSM adapter, not GPS, right? Yep, was late when I took the photo. Sorry. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
external GSM antenna
The GSM-connector to be found near one of the screws (see [disassembling Neo 1973] in wiki) is: MURATA MM8430-2610RB3 SMD RF TEST PORT For a nice fitting adapter see attached photo and: http://www.google.de/search?q=MXHS83QE3000 Sorry folks, didn't find a page to add this to wiki. Hope someone else will... ;-) HTH jOERG <> signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reply above Quotation
PLONK Am Mo 28. Juli 2008 schrieb arne anka: > > using examples of obviously bad quoting to advocat TOFU seems strange > > those "examples of obviously bad quoting" are a great majority of mails. > it so happens that i am tired of scrolling down endless mails is imple > skip them totally ... > i've said it already, but you did obviously not care to read my reasoning > instead crusading for an abstract rule of social life. > > > to me. i don't know what is worse in this case. the dicease or (your) > > "cure". > > the whole discussion is rather pointless because > - the missionaries of bottom postings usually are not interested in > reality but in some kind of educating the public, that's at least my PLONK > experience (and the argumenta ad personam are proof of it). > - a lot of writers of this list do not read faqs or archives and thus are > not concerned by such debates. the only hope is common sense, not tofu vs > fotu. > > if you had read my mail you should have understood that my concern was > readability, not some abstract principle. > PLONK PLONK PLONK > > since i made my point long ago i will not answer any mail regarding this > topic. > it's nothing but noise without any use. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > PLONK PLONK PLONK PLONK PLONK PLONK PLONK PLONK /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: USB connector not Mini-AB?
Am Mo 28. Juli 2008 schrieb Andy Green: > It does not mention mini-AB there, it only mentions micro-AB, so now I > know even less than I did when I started :-) so doesn't http://www.usb.org/developers/devclass_docs/CabConn20.pdf Seems there's no such thing like a standardized mini-A, and thus for sure no mini-AB :-/ ??? cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: trying to buy a freerunner in taipei?
I seem to remember a note from Sean about us trying to find a way to make this possible. Thanks for the note on our phonesystem! Right now I would guess we don't have the infrastructure to sell devices to our customers directly, off the office. But let's see... cheers jOERG Am So 27. Juli 2008 schrieb tony: > Robert Schuster <[EMAIL PROTECTED]> writes: > > > I want to encourage you and the other people from Taiwan to get into > > contact with OpenMoko staff. Maybe write to Mickey Lauer, Sean > > Moss-Pultz or Steve Mosher directly and tell them your problem. They > > post messages to these lists, too. > > > > Perhaps you could also open a bugzilla ticket. :) > > > > Robert, > thanks for the encouraging insights. > > I'm guessing that the OpenMoko management staff have their hands full with > logistical issues what with the new release of the FreeRunner. > Direct email might be a bit invasive. > > I've actaully tried calling them, but their phone system is broken or something. > It says I should dial 9 for operator, but then it just hangs up. :( > > I figured when they have time they will read this mailing list and hopefully, if > possible, act upon our comments. > > Cheers, > Tony > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The GTAs
Am So 27. Juli 2008 schrieb robert lazarski: > On Sat, Jul 26, 2008 at 4:51 PM, Joerg Reisenweber <[EMAIL PROTECTED]> wrote: > > Am So 27. Juli 2008 schrieb Marko Knöbl: > >> according to http://en.wikipedia.org/wiki/Openmoko GTA04 "will likely > >> have 3G support" as well. Is that correct? > > nope > > /j > > > > Is no 3g motived by hardware limitations , licensing problems, or a > decision from the silent and mysterious "design" department ? > > > I'm not a developer ATM machine, ie, I won't keep buying these devices > and developing on them if they never will have competetive hardware. I > Already bought the Freerunner thinking the hardware on a future device > will someday catch up to the current proprietary market. Now I > realized that is not going to happen. I can't figure out the > "evolution, not revolution" purpose of the GT03 , and now that GT04 > won't have 3G , it makes me wonder who are going to buy these things. > My pockets and patience are not endless. > Sorry my fault. GTA04 is completely unclear yet. I read GTA03, where in fact you asked for 04. Nevermind. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The GTAs
Am So 27. Juli 2008 schrieb Marko Knöbl: > according to http://en.wikipedia.org/wiki/Openmoko GTA04 "will likely > have 3G support" as well. Is that correct? nope /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
community@lists.openmoko.org
The long version is: you can't readout the encryption key from new simcards. Gifted hackers have resigned on this. If you come up with a solution, you'll probably on title page of quite some papers ;-) See a thread on this some weeks/mnths ago here n one of the ML cheers jOERG Am Sa 26. Juli 2008 schrieb Adam Talbot: > "can't" is such a horrible word :-) > I have been told that many time about installing Linux on different > peaces of hardware. I have 30+ SIMs to burnout, destroy, or otherwise > use as guitar picks. The long version would be? > -A > > > On Sat, 2008-07-26 at 11:00 +0800, Joerg Reisenweber wrote: > > Am Do 24. Juli 2008 schrieb Adam Talbot: > > > Could I get around this with a SIM card burner? Is there such a thing? > > > Copy the 71234O SIM onto one of my old SIMs? > > > -Adam > > GSM-SIM can't be copied [short version] > > /j > > signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ringtone and vibration configuration
Am Sa 26. Juli 2008 schrieb Dylan Reilly: > I am hoping to make some scripts, etc. for incoming call scenarios. > > 1) What mixer setting in alsamixer controls the ringtone volume? > 2) What alsa profile is used when a call is first incoming? gsmhandset.state? > 3) How can one control the state of the vibrations (on, off, and ideally etc.)? Please note I consider our concept of restoring a *complete* mixer setting by alsactl somewhat limited (not to say brain damaged) If I need a special scenario to push out a ringtone via speaker, this shouldn't affect any record setup i did for mic for use with some completely different concurrently running app (please find "better" examples if you're about to say "mic will catch ringtone sound"). Also switching from headset.state to speaker.state is done without regarding those are mutually exclusive setups, and speaker mustn't be used while headset is plugged. :-( Doing setup modification just for the mixer elements that are actually needed, by some amixer script, looks like a more sane way to me Just my 2 cents /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How can I hear Music with A Headphone
Please see http://lists.openmoko.org/pipermail/community/2008-May/018312.html and complete thread. Somewhere in there I already gave pointers to adapters that should fit. Anyway with info from this thread you might figure out by yourself. HTH /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The GTAs
Am Sa 26. Juli 2008 schrieb Flemming Richter Mikkelsen: > > USB2.0-OTG > Yes. OM pays a lot for this. NOPE! > > > > GTA04 > > USB2.0 will be here at the earliest look here! /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
community@lists.openmoko.org
Am Do 24. Juli 2008 schrieb Adam Talbot: > Could I get around this with a SIM card burner? Is there such a thing? > Copy the 71234O SIM onto one of my old SIMs? > -Adam GSM-SIM can't be copied [short version] /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: strange problem with Intenso 4GB SDHC card
Am Do 24. Juli 2008 schrieb Andy Green: > Somebody in the thread at some point said: > | Hi all, > | > | I can now reliably reproduce the issue, as dd'ing the mbr back to the > | card so far restores sane behaviour : > | > | If sd_drive is set to "0", then after a resume from "sync && apm -s" the > | MBR of my 4GB SanDisk is wiped - so far I haven't noticed any other > | errors, but have not looked very closely. > ... > > | PS: Can somebody please tell me how to re-initialize the card without > | going through another suspend/resume cycle ? > > sd_drive setting isn't actually used until next time we access the card, > so provoking an access will do it, eg, touch /something ; sync. > > But the two explanations for what goes on seem mixed still here, we > affect sd_drive and we do a suspend. My guess / hope is that this > problem is coming from the suspend action alone and the change of > sd_drive is bogus here. Maybe you can bang on it a little more trying > to disprove that hypothesis? > > -Andy As I think this seems to be quite a good clue to what's really happening here, quote from the OLPC ticket #6532: (HTH) > cc dilinger added I've spend some time digging deep into the bowels of the VFS and block layer and gathering some debug output and have an explanation for the partition table corruption: Upon coming out of resume, the SD code, with CONFIG_MMC_UNSAFE_SUSPEND enabled, checks to see if there is a card plugged into the system and whether that card is the same as the one that was plugged into the system at suspend time. This is accomplished by reading the card ID of the device and for some reason, very possibly #1339, we fail this detection. In this case, the kernel removes the old device from the system and in this execution path, the partition information for this device is zeroed. Even though the device is removed, the device is still mounted and upon unmount, ext2 syncs the superblock, even if the file system is sync'd beforehand. The superblock is block 0 of the partition and the block layer adds to this the partition start offset before submitting the write to the lower layers. As the partition information has already been zeroed out, we end up writing to block 0 of the disk itself, overwriting the partition table and the geometry information. I've verified this by both gathering debug output and 'dd' + 'hexdump' of corrupted and uncorrupted media. Some interesting points: We are able to delete a block device even though it is still mounted. Even though the device has been deleted, the write submitted to it does not fail. Note that this is still not 100% reproducible and in certain cases the superblock write during unmount does fail with block I/O errors, meaning that the queue is properly deleted. As per dilinger's comments on IRC, the VFS has lots of refcounts and there is a timing issue/race condition that we're hitting. As per #1339, we may be able to add an OLPC specific hackto wait 500ms or so upon resume to get around this. I will try this but I don't think this is acceptable given our suspend/resume requirements. Something I don't quite understand at the moment is how/when our userland env (journal specifically I think?) unmounts the device as I've been testing via command line suspend mount, and unmount while running in console mode. Next steps: Get an understanding of the what is happening with our userland and brainstorm with cjb about the possibility of simply unmounting the SD device upon suspend. There are issues around this as we may have files open and that will keep us from suspending. Test adding a timeout to the resume path to see if it solves our problem to validate that it is indeed something related to our HW. Dig into the unmount/write to non-existing bdev some more nad discuss this upstream if needed. (Adding dilinger to cc:) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Max seep of the SD slot?
Am Fr 25. Juli 2008 schrieb BlueStar88: > What about fixing the rate on the sd-card side to far lower level, not > only while ideling, even if accessing? Lets say 5MHz. Would it make any > sense and would it decrase the clock noise significally enough, to be > able to just ignore the hardware patch? To add to Andy's prev comment, the noise isn't exactly relating to clock-*speed* but rather to signal rise- and fall-time of the low-high-low transitions. Those aren't affected by mere closck-speed, but actually are by adding caps or changing drive-power. Think of it like hitting a bell once a second or every 3 seconds doesn't change the frequency or amplitude of the bell's tone itself. Anyway fiddling with sd-clock-freq won't hurt, just report your results. Maybe we find something unexpected ;-) cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS success: updated default software stack with no antenna
Am Do 24. Juli 2008 schrieb Jay Vaughan: > > Successfully tracked and mapped my daily commute! > > > Me too, daily, twice a day since Monday .. > > ; > -- > Jay Vaughan Wooohoo!!! Finally! /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problem booting to NOR?
Am Do 24. Juli 2008 schrieb Mike Montour: > A Freerunner without a working NOR flash is basically the same as a > Neo1973. It's safe to flash a new kernel or rootfs partition; the risk > of bricking the device is only if you update u-boot itself. Yeah, so *WATCH YOUR "-a " PARAMETERS* when flashing! Flashing false image to -a u-boot is definitely bricking your device then. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Volume?
Am Sa 26. Juli 2008 schrieb Al Johnson: > I've also been annotating the block diagram of the chip with the numbers of > the ALSA controls they're tied to so it should be easier for people to work > out what does what. It's not finished yet, and I won't have time to post it > before next week. GREAT! urgently needed! Thanks, I may scrap it from my todo list now :-) /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Operation without battery (GTA02) / sysfs wiki page
Am Mi 23. Juli 2008 schrieb Andy Green: > Somebody in the thread at some point said: > > | | Is there a Wiki page or docs that explain what each register is and > | the units it refers to? > | | especially in the .../power_supply/bat/... area which seems to have > | very pertinent information. > | > | I think I will start one. There's some real gold down the /sys mine if > | you are interested in meddling. > > I made a start on documenting the more interesting /sys files here: > > ~ http://wiki.openmoko.org/wiki/GTA02_sysfs GREAT! /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA01BV4 died, please help me.
Am Do 24. Juli 2008 schrieb Michael Shiloh: > > Joerg Reisenweber wrote: > > Am Mi 16. Juli 2008 schrieb Michael Shiloh: > >> Joerg Reisenweber wrote: > >>> This shouldn't cause any problem on GTA02 (on GTA01 there were some scream > > of > >>> death issues when removing bat while charged IIRC). At least we have no > >>> reports on this so far, I myself do remove bat while on charger > > frequently - > >>> no harm. > >> > >> The original post is regarding a GTA01 in fact. > > > > Sorry, my fault > > Yes GTA01 is reported to be problematic on removal of bat while charging. You > > shouldn't do this. Alas this is "before my time" and I can't actually > > remember all the details I've been reading on this, nor could I tell about > > possible harm caused by this. > > /jOERG > > Joerg, if you have a chance while in TPE (perhaps during casual > conversation in the elevator or whatever), could you find out if anyone > knows what exactly gets damaged? > > If this is something that can be replaced it would be the best, but it > would be very useful information both to the customer and to us if it's > something that can be tested (visually, with multimeter, with 'scope) so > that the cause of their GTA01's premature death is known. For all I can imagine here's nothing else than the PMU PCF50606 that's going to fry. Battery isn't connected to anything else. PMU is hard to replace (vitualy impossible). All this only wild guess, not confirmed. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS software fix, just CRUFT?
Am Di 22. Juli 2008 schrieb Scott Derrick: > With the GPS hardware fix done(10pf cap installed) are the software > changes to the kernel/modules just added cruft? IE. do they add > anything useful? SW is definitely better than C, it works on data-rails as well. Those might spill GPS during access even while the clock is fixed by a C. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: USB connector not Mini-AB?
Am So 20. Juli 2008 schrieb Tobias Diedrich: > Torfinn Ingolfsen wrote: > > Hello, > > > > 2008/7/19 Tobias Diedrich <[EMAIL PROTECTED]>: > > > Looking at the Freerunner connector, it looks like it's really a > > > Mini-B Female connector instead of the Mini-AB Female connector as > > > stated on > > > http://www.openmoko.org/wiki/Neo_FreeRunner_GTA02_Hardware > > > > > > Can someone else confirm this? > > > > Yes. See > > http://www.openmoko.org/wiki/Getting_Started_with_your_Neo_FreeRunner#Package_Contents > > Well, that doesn't contradict with a Mini-AB female connector though. > As it's name says a Mini-AB femal connector should accept both > Mini-A and Mini-B cables, which makes sense because Mini-B is used > for client mode and Mini-A for host mode and the Freerunner supports > both. > > The wrong connector means that an 'offical' USB-OTG cable like > http://www.amazon.de/Hama-00074214-OTG-Kabeladapter-Mini-USB-A-Stecker-USB-A-Kupplung/dp/B000EORX7U/ref=sr_1_1?ie=UTF8&s=ce-de&qid=1216581564&sr=8-1 > can't be used unfortunately... > > And I can't find a USB-A receptacle to Mini-USB-A plug cable on amazon. :/ > Only this plug-adapter (maybe, it does not explicitly state A or B > AFAICS), which will work I guess, but I'd rather like a cable. > http://www.amazon.de/Adapter-BUCHSE-Stecker-Verl%C3%A4ngerung-Anschluss/dp/B001372BVA/ref=sr_1_44?ie=UTF8&s=ce-de&qid=1216581654&sr=8-44 > Seems like I'll have to cannibalize the Hama cable. ^_^; see: http://www.electronicproductonline.com/catalog/product_info.php?products_id=1781 /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Am So 20. Juli 2008 schrieb Scott Derrick: > Problem there is the rule based engine is trying to decide to answer the > call, put it to voice mail, vibrate, ring loud, etc... Waiting 30-60 > seconds for a cold start fix from the GPS is too long. But you can listen to mic to determine on ambient noise - just a few seconds maybe, or even after first gentle ringtone, and then adjust ringtone volume accordingly (pat. pend. jOERG ;) Also you can check the *echo* of the ringtone to decide whether you're in a silent room, in a pocket, under open sky... (pat. pend. jOERG ;) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Battery Lifetime
Am So 20. Juli 2008 schrieb Flyin_bbb8: > what's the hungriest of all? or if we can have a list of all the hungry > stuff in the FR sorted from the one starving to the one who needs a snack? GSM-active-call/GPRS data TX [up to 2A peak, 1A avg] (USB-host mode [up to [EMAIL PROTECTED]) LCM-light LCM-light LCM-light WiFi active TX Speaker CPU, BT, glamo, RAM... etc signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proper mixer settings for music playback, or hardware fixes?
Am So 20. Juli 2008 schrieb Timo Jyrinki: > 2008/7/18 Hans L <[EMAIL PROTECTED]>: > > Just a guess here since I haven't even had a chance to look at these > > settings yet, but maybe the second frequency(after the @ symbol) > > represents the sample rate? So depending on the sample rate you are > > playing, you can set a different bass frequency cutoff? > > 2008/7/18 Joerg Reisenweber <[EMAIL PROTECTED]> wrote: > > Please refer to Wolfson WM8753 datasheet - link to be found on wiki > > I checked the datasheet. Indeed it means sample rate, but one that > scales. There's a table specifying eg. that if you select 100Hz > cut-off @ 16kHz, it means that at 48kHz the cut-off is 300Hz. I guess > the names in alsamixer have been chosen according to even numbers, so > that they actually really scale from lowest setting to highest. > > It's just that the scale seems to be opposite to reality, ie. the > highest cut-off frequency actually results in the lowest. Most > probably the setting I chose (200Hz @ 8kHz -> 1200Hz @ 48kHz) actually > represents 130Hz @ 48kHz, and the one named as such (130Hz @ 48kHz) is > in reality that 1200Hz @ 48kHz since it sounds so thinny. > > Problem solved, the cut-off is 130Hz which is quite high for > headphones but ok for portable speakers. nah, this is +-3dB point - not exactly cutoff. so if you select 130Hz @ 48kHz and try to boost bass frequencies you get poor results, as there is only a boost of frequency below 130Hz. It's not reversed, it's just not cutoff frequency if you chose positive value for bass level. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SIM card works with qtopia, not ASU or Factroy Image
Am Sa 19. Juli 2008 schrieb Greg Bonett: > Has anyone else had a similar experience? My SIM card works reliably > with qtopia but not with ASU or the factory image. I have an ATT 3G > 71234 4002 sim card. Image: (http://www.gregbonett.org/sim.png). > > I've attatched 'logread -f' output for ASU and qtopia. > > Is looks like some of the SIM issues are not hardware related but > software issues. > > -Greg > please don't hijack threads! /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
Am Sa 19. Juli 2008 schrieb Tommi Kärkkäinen: > Neng-Yu Tu (Tony Tu) kirjoitti: > > But this work still not suggest do by yourself, also, this fix need > > proper size capacitor (10 pf with 0402 package), and some solder technique. > > Is there a specific tolerance requirement for the capacitor? Nope /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dot'n reply above quote
Am Sa 19. Juli 2008 schrieb Yocto: > One more thing I like with other mailing lists. > They start their subjects with a token describing their mailing lists in > square brackets. > This allow to quickly sort / filter the incoming mails. > > Examples: "[jQuery]","[Qemu-devel]", "[ECOS]", "[Rtai]", "[vlc]" > > It would be nice to see the Openmoko mailing list use something like: > "[OpenMoko]", "[OM]" or "[FR]" Aaw, no! not this one again! Please have a look at full expanded header of your mails! filter for mailing-list, not subject. All decent MUAs allow to do this. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reply above Quotation
Am Sa 19. Juli 2008 schrieb Charles Pax: > On Fri, Jul 18, 2008 at 8:34 PM, Scott Derrick <[EMAIL PROTECTED]> wrote: > > > If your going to quote the email your replying to, please reply above > > the quotation. > > > I find it much easier to read a conversation when the reply is below > original message. please use posting / quoting style according to RFC1855 http://tools.ietf.org/html/rfc1855 and see http://en.wikipedia.org/wiki/Top_post ''Some believe that "top-posting" is appropriate for interpersonal e-mail, but inline posting should always be applied to threaded discussions such as newsgroups.'' /jOERG A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Enter/Return key on Asu (illume) Keyboard
Am Fr 18. Juli 2008 schrieb Sven Klomp: > How can I access the Return/Enter key? I already tried to make my own layout > including Return but with no success. > > Sven strike left-to-right over keyboard /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ekiga for Openmoko, petition,
Am Fr 18. Juli 2008 schrieb andres: > Hi, > > As I feel anxious about running an extension of my asterisk in the > Freerunner, What's the use in running * on FR? maybe you could run * on your (home)server, on FR you probably like a decent UA aka client /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ekiga for Openmoko, petition,
Am Fr 18. Juli 2008 schrieb Florian Rebstock: > Twinkle sounds good, not least because ZRTP/SRTP is supported without zfone. > > > Am Freitag 18 Juli 2008 22:11:24 schrieb Greg Bonett: > > I think its important we get a SIP client working ASAP on the FR. Maybe > > we should focus on Twinkle since it supports ZRTP/SRTP. I strongly second this (ok, I'm biased ;) Twinkle is rocksolid, and it's completely platform agnostic (as far as Michel de Boer was able to). There's even a commandline version you can build with mere make options. see --without-kde --without-qt --dunno-what Only thing I don't like are some of the libs used and the way those are maintained. cheers joerg.twinklephone AT gmx dot de twinklephone.com signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Camera support on OpenMoko?
Am Fr 18. Juli 2008 schrieb Yocto: > I agreed, especially when the SC32442B has a camera interface. 2442 cam-IF is unused on FR/GTA02, and no way to put it to work. Support for USB-cam is same as you see on any distro. Nothing special. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proper mixer settings for music playback, or hardware fixes?
Am Fr 18. Juli 2008 schrieb Hans L:
> On Fri, Jul 18, 2008 at 6:17 AM, Timo Jyrinki <[EMAIL PROTECTED]>
wrote:
> > I found that Bass Filter has a scale going from most normal ("200Hz @
> > 8kHz") to most thinny voice ("130Hz @ 48kHz"), but how those settings
> > should be interpreted?
>
> Just a guess here since I haven't even had a chance to look at these
> settings yet, but maybe the second frequency(after the @ symbol)
> represents the sample rate? So depending on the sample rate you are
> playing, you can set a different bass frequency cutoff?
> But, honestly I have no clue, hope I'm not confusing the issue any
> more than it was.
Please refer to Wolfson WM8753 datasheet - link to be found on wiki
/jOERG
signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
This should go to Steve and Michael, I guess Am Fr 18. Juli 2008 schrieb C R McClenaghan: > Tony, > > Will OpenMoko offer this repair to Freerunner owners? How and under > what terms? > > Chris > > On Jul 18, 2008, at 2:28 AM, Neng-Yu Tu (Tony Tu) wrote: > > > Dear Community: > > > > For GTA02 SD card interference GPS issue, our hardware team provide a > > hardware fix/workaround for this coexistence bug. Sorry post it late, > > because we have to make sure this fix works and don't have side > > effects. > > > > Here is the fix: > > > > http://www.openmoko.org/wiki/Image:Gta02_gps_10pf_rework_sop.pdf > > > > This fix could give almost same performance with SD card out of case. > > > > But this work still not suggest do by yourself, also, this fix need > > proper size capacitor (10 pf with 0402 package), and some solder > > technique. > > > > We saw people ask about service issues of Openmoko devices, and we are > > working on it. Our sales discussing with our distributor about proper > > services model, but do not have consensus yet, I will keep update it. > > > > Thanks, > > > > Tony Tu > > > > Openmoko, Inc. > > > > Support > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
Am Fr 18. Juli 2008 schrieb Carsten Gerlach: > Hi at all, > > Am Freitag 18. Juli 2008 11:28:29 schrieb Neng-Yu Tu (Tony Tu): > > > > Here is the fix: > > > > http://www.openmoko.org/wiki/Image:Gta02_gps_10pf_rework_sop.pdf > > What is with the _new_ FreeRunners on the production line? Do they have this > fix already when they leave the manufactory? I guess and hope so. AFAIK, this rework is already done on all FR you can buy or order right now. (what do you think we're doing here? ;-) /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Timezones not used everywhere?
Am Fr 18. Juli 2008 schrieb Flemming Richter Mikkelsen: > On 2008-07-18, Hans L <[EMAIL PROTECTED]> wrote: > > On Thu, Jul 17, 2008 at 5:11 PM, Olivier Migeot <[EMAIL PROTECTED]> wrote: > > > I'm using an "un-crippled" (according to the "Freerunner Quickstart" > > > wiki page) GTA02, with factory image (only opkg upgraded tonight). I > > > display a digital clock on my home screen, and it also displays the > > > date in the bottom. For I'm living in France, I made the > > > /etc/localtime symlink to the Europe/Paris tz (GMT +2, these days). So > > > far so good, the time and date were both displayed correctly. > > > > > > And then, maybe an hour or two before midnight (I couldn't guess so I > > > didn't check precisely, but I will next time), as hours/minutes stayed > > > correct, the "date" field went wrong. Well, not exactly "wrong", but > > > "tomorrow". Like few hours too soon. Sounds to me like the "date" > > > field is using universal time when it should not, but I can be wrong. > > > > > > Any idea/insight on this? > > > > > > Thanks alot... I hope it was clear, for it's already time to sleep here. > > > > > Does openmoko get any time/date information from the cell towers? > > With previous phones I have owned, I don't remember ever having to set > > a timezone. And when traveling across timezones, it seems to > > automatically pick up the change from the cell phone towers. Is there > > a way we can make openmoko retrieve this information itself, so it > > never requires any manual configuration? > > > We can detect the network and look it up in a list and map it to a country:) There seems to be sort of time msg on some gsm-networks. Though it's messy sometimes, it seems. Please search lists, there've been prev.posts on this /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
Am Fr 18. Juli 2008 schrieb Roland Mas: > Timo Jyrinki, 2008-07-18 13:42:02 +0300 : > > > Does anyone else have a reliability problem now with the new kernel > > and GPS when SD card is used? > > I have. Didn't manage to properly isolate the problem, but my gut > feeling is that Andy's patch to disable SD when acquiring the first > fix does only that for, well, the first fix. *Apparently*, there are > circumstances where running agpsgui once, getting a fix, exiting and > restarting afterwards, doesn't result in the FR getting a new fix. As > you said, rebooting solves the problem, but suspend/resume cycles > don't seem to reliably fix it. > > Roland. > -- > Roland Mas Sorry! There's *no* disabling of SDcard for FF! Who's talking about suspend/resume cycles, did I miss sth? Please read the appropriate posts describing the way this patch works. Otherwise, please don't conclude on false assumptions, but just report what you observed. Thanks for regarding this, helps a lot! cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
Am Fr 18. Juli 2008 schrieb JW: > Overall, getting indoor gps fix at all is pretty impressive - SIRF III is > great chipset. Just we're using u-blox antaris chip ;-) (nearly as good, or maybe even better) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hot Pocket
Am Fr 18. Juli 2008 schrieb shawn sullivan: > Does anyone else's FR run really warm? I had mine in my pocket last > night for a few hours and my leg got really toasty!! > > . . .shawn So let's think about it: we have ~3.8V of battery voltage, and 1.2Ah. Gives me a 4.5Wh of energy in battery. Let's assume we burn all of this in "a few hours" (maybe 4.5h), we get a continuous power of 1W. H... Maybe just noticeable for a sensitive individual, but sure not enough for "toasty". Probably FR is hot stuff anyway, so that's what you're feeling? ;-) cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proper mixer settings for music playback, or hardware fixes?
Am Fr 18. Juli 2008 schrieb Al Johnson: > On Friday 18 July 2008, Ole Kliemann wrote: > > On Fri, Jul 18, 2008 at 02:17:05PM +0300, Timo Jyrinki wrote: > > > I had heard > > > about some resistor in wrong place resulting in high-pass filter and > > > basically making music listening unbearable. > > > > Do you still remember where you read it? > > > > I have some problems with the output of the headphone jack too. But to > > me it sounds mostly distorted. > > http://lists.openmoko.org/pipermail/community/2008-June/019938.html > http://lists.openmoko.org/pipermail/openmoko-kernel/2008-March/001994.html You see, though I'm in a much better position now, I still didn't make it yet for this to come true, to fix it for good, against the powers that be. :-( My apologies to all of you for this. Stay assured this issue isn't forgotten, I'll struggle on cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Battery Lifetime
Am Fr 18. Juli 2008 schrieb arne anka: > > You and Arne are quite right, suspend is subject to random wakes from > > GSM world too at the moment and that can lead to the same result. > > Carsten wants to deal with wakes in his daemon so we're waiting on that. > > > is there a way to detect when it wakes? a hook to plug custom actions > into? then, as a workaround, we could check what caused the resume and put > it back to sleep immediately or at least disable the screen. That's what Carstens daemon is all about! ;-) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Battery Lifetime
Am Fr 18. Juli 2008 schrieb arne anka: > > Touchscreen is not a "wake from suspend" source, so as you suggest it > > didn't get to suspend to make this trouble. > > not sure i understand you correctly, but several times i experience that > the fr, while seemingly in suspended state, answers to a screen tap > showing several console messages (whihte font, black background) and then > switching to the lock screen. > > otoh, what i meant was: when the fr frequently wakes up the screen becomes > sensitive and any tap would prevent the fr from going back to suspend -- > so if in one of these moments of short resumes the screen ist tapped and > again and again the fr would never resume thus draining the battery > quickliy. And what is it that stops us from disabling ts, just reenabling it when we see a valid wake-source to stay in user-land (e.g. inbound call, RTC, powerbutton...)? /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Battery Lifetime
Am Fr 18. Juli 2008 schrieb Adam Talbot: > I just got a running SIM card :-) > My FR likes to resume at lease once a min. If you were to take a > "stealth" approach, it would be doing 100's of resumes in a day. Which > is fine, if you want to test resume ;-) What's wrong with 100's of resumes / day, as long as each one takes no longer than 2~3sec, and is on low power profile? > I think we need to block this at a uBoot level. Perhaps a black list of > events? Nah, can't be done. Completely wrong concept. /j > -Adam > > On Fri, 2008-07-18 at 01:14 +0200, Joerg Reisenweber wrote: > > Am Do 17. Juli 2008 schrieb Mathieu Rochette: > > > On Thu, Jul 17, 2008 at 10:41 PM, Andy Green <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > Carsten has started on a daemon to handle wakes in userspace that should > > > > eventually parse this and figure out if it can go back to suspend > > > > silently once the wake reason was serviced. > > > > > > > > > should it be possible to disable a reason prior to suspend? > > > eg: echo 0 > /sys/somewhere/reasons/touch_screen > > > > > > maybe there will still be some case that can't be handled (eg: don't annoy > > > me for 2 hours) but I think that could cover mosts. > > > > > > > Of course this could be handled: just use RTC to resume after 2h of "DND", and > > block all resume reasons you don't want to see FR wakes on during that time > > (or handle them "stealth mode" with the upcoming deamon Carsten is about to > > write). > > /j > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Battery Lifetime
Am Do 17. Juli 2008 schrieb Mathieu Rochette: > On Thu, Jul 17, 2008 at 10:41 PM, Andy Green <[EMAIL PROTECTED]> wrote: > > > > > > > > Carsten has started on a daemon to handle wakes in userspace that should > > eventually parse this and figure out if it can go back to suspend > > silently once the wake reason was serviced. > > > should it be possible to disable a reason prior to suspend? > eg: echo 0 > /sys/somewhere/reasons/touch_screen > > maybe there will still be some case that can't be handled (eg: don't annoy > me for 2 hours) but I think that could cover mosts. > Of course this could be handled: just use RTC to resume after 2h of "DND", and block all resume reasons you don't want to see FR wakes on during that time (or handle them "stealth mode" with the upcoming deamon Carsten is about to write). /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ears and FR
Am Mi 16. Juli 2008 schrieb Joseph Reeves: > I do it all the time ;-) > > I'd like a keypad lock during calls. I know that there's some options > available during a call, but I'd much rather have to unlock them > first. Of course, it doesn't have to be a lock that's particularly > difficult to un-lock - pressing the aux button before the screen does > anything would be great. Use the g-meters / gestures! FR on ear -> locked. FR in front of face -> unlocked. Also simply placing buttons on bottom of screen instead on top might help a lot. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS problems, summary
Am Mi 16. Juli 2008 schrieb Yorick Moko: > no fault or wrong conclusion but I just want to add that Andy also > made a patch to crank up the voltage a bit for the GPS unit > Yep, but this one didn't help at all it seems. One flaw in OP's summary: the recent andy-sd_clock-patch doesn't block sd-card for benefit of GPS FF. It simply switches off clock of sdcard as long as we don't read from it (or write). So you still can spoil TTFF by *constantly* reading from SDcard, but GPS seems to be fine as long as you don't do this. Stopping sd-access during TTFF is a userland issue. Kernel mustn't block sd-reads for extended periods, we might see all kinds of deadlocks if we did it this way. For sure answering an inbound call is higher priority than shortest possible time for this particular FF, no? So maybe you have your ringtones on sd. U see? rootfs on sdcard might be an issue, we (community?) should give this one a test cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fwd: Freerunner // GPS Fix per Software
-- Weitergeleitete Nachricht -- Betreff: Freerunner // GPS Fix per Software Datum: Mi 16. Juli 2008 Von: Stan Behrens An: [EMAIL PROTECTED] Hallo Joerg, war gerade dabei nen paar Messungen zu machen, Ergebnisse: uImage-andy-20080716, no sd, window 1. 72 2. 68 3. 78 uImage-andy-20080716, sd, window 1. 109 2. 65 3. 85 uImage-2.6.24+git15+0f565eebf6f9a52a66053348aa710e05732f934e-r0-om-gta02, no sd, window 1. 107 2. 57 3. 117 uImage-2.6.24+git15+0f565eebf6f9a52a66053348aa710e05732f934e-r0-om-gta02, sd, window 1. >600 2. >600 3. >600 Hoffe ich konnte helfen, die Entdeckung mit der SD-Card war ein huebscher Zufall :) Bye, Stan Behrens. --- signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AW: RE: unable to start up freerunner after batterie was full down
Am Mi 16. Juli 2008 schrieb Michael Shiloh: > > Joerg Reisenweber wrote: > > > Jumpstart the battery is very unlikely to help you out. > > > > Joerg, can you explain this further? > > I've actually had excellent luck jump-starting the battery. I set my > adjustable power supply at about 4.5V and I connect it directly to the > battery terminals for just a second, then measure the voltage on the > battery. If the battery voltage is still zero, I repeat. Usually after a > few "shocks" the battery comes out of its internal under-voltage protection. > > I understand that GTA01 batteries have no hysteresis and need just one > "shock" (in fact Werner said "one electron" I think) to come out of > under-voltage protection. I understand that GTA02 batteries have > hysteresis and require more coulombs injected before they will recover. I'm just suspicious a shock-reanimated battery holds enough power (=voltage) to bring us over the boot gap, and won't activate protection again just in no-time when we try to pull energy. That's all. Of course you can shockstart battery out of protect-mode, no doubt. But did you get a boot with such a bat? /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Operation without battery (GTA02)
Am Mi 16. Juli 2008 schrieb Alexey Feldgendler: > I have two 100% reproducible issues with my GTA02. > > 1. When running with the battery in (charged enough) and a USB cable > plugged into a computer, removing the battery makes the phone die. It > seems to turn off several seconds after the battery is removed. Probably GSM trying to pull ~2A for transmitting. This will make the device shut down instantly. Try disabling GSM! > If the > battery is replaced quickly enough, the phone doesn't turn off. While the > battery is disconnected, some things still run and some seem to stop; e.g. > the GPS chip stops sending NMEA sentences but continues doing so when the > battery is put back. > > 2. When the phone is off with no battery in it, plugging the USB cable > connected to a computer makes the phone emit a buzzing noise. The noise > continues until the cable is disconnected. The phone won't start up in > this state, not even in the NOR menu. I remember a similar issue in GTA01, > but GTA02 was supposed to work without a battery. That's related to the "can't startup on flat battery"-issue. Please refer to this thread. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA01BV4 died, please help me.
Am Mi 16. Juli 2008 schrieb Michael Shiloh: > > Joerg Reisenweber wrote: > > This shouldn't cause any problem on GTA02 (on GTA01 there were some scream of > > death issues when removing bat while charged IIRC). At least we have no > > reports on this so far, I myself do remove bat while on charger frequently - > > no harm. > > > The original post is regarding a GTA01 in fact. Sorry, my fault Yes GTA01 is reported to be problematic on removal of bat while charging. You shouldn't do this. Alas this is "before my time" and I can't actually remember all the details I've been reading on this, nor could I tell about possible harm caused by this. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
Am Mi 16. Juli 2008 schrieb Jay Vaughan: > > However,.. one must really think why this problem didn't turn out in > > the > > factory tests :-( > > > Yes. That is indeed something that must be thought about. > > ; > -- > Jay Vaughan Tony Tu already posted a response to this: Our factory tests can't be done under real live situation, we have to create an 'artificial' GPS signal to test. Our tests with this artificial signal didn't show any issue, even when tested with uSD inserted, which was one of the tests. Please note: Even out in the wild there have been reports of decent fixtime with uSD *inserted*. So this is a +-3dB issue, where we didn't recognise our tests at fab were *a little* 'overoptimistic' with regard to real live. This has been addressed by our production engineers last week and already should be fixed by now. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
Am Mi 16. Juli 2008 schrieb Kalle Happonen: > Marcus Bauer wrote: > > The same goes for making phone calls: there is quite often a buzzing > > sound on the far end and it can be really bad. Unless you don't care > > about the people you are calling the Neo is not usable as your daily > > phone. > > > This IMHO is a much bigger problem, which has caught much less attention. *not* on developer side. We're on it. Alas that's a much more tricky one. See my previous posts on this particular topic, all across the lists. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
Am Mi 16. Juli 2008 schrieb Jay Vaughan: > >> Its really pretty important that the communication on this issue > >> *not* > >> diverge into hate and vitriol towards customers, because to those who > >> are observing the OpenMoko project - not participating - the SD+GPS > >> testing issue is a *huge* screw up. > > No, the SD+GPS issue is a bug. > > Context:SD+Glamo == No go. > SD+GPS == No go. > > How many GTA02's have been shipped before this problem was > discovered? How much time wasted trying to get GPS functioning so > that development can continue? Sorry? What's your point here? > > > > Admittedly a somewhat nasty bug, but > > nothing extraordinary. > > If I can't use SD+GPS, its a no-brainer: Freerunner is no longer > qualified for my project. Having spent a year on OpenMoko, thats > nasty. I was willing to give the SD+Glamo issue a slide, but .. We understand this pretty good. but please, pretty please could you write posts like yours above with a somewhat more explicit lettering, like >> **IF** I can't...<< Chances are all your rant is moot. There is a solution at horizon. your post sounds like OM has betrayed on you. In fact we are very busy to fix things, and we think we *will* get them fixed. This is developer release. Stay tuned for instruction to fix. /jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
