Re: SHR Unstable
Am Fr 3. Juli 2009 schrieb Paul: I am unable to get GPS to work and GPRS tends to lock things up. Also the Wifi is iffy. These bugs, though annoying, still allow me to use the phone. I think getting the device to have a stable gprs connection is the next big step. Please update to moko11 [1], and use abyss instead of gsm0710muxd [2]. This fixes some issues with flowcontrol that may break GPRS, though it's not yet verified to address all related flaws. cheers jOERG [1]http://wiki.openmoko.org/wiki/GSM/Flashing [2] opkg install fso-abyss sed -i.orig -e 's/_type gsm0710muxd/ fso-abyss/' /etc/frameworkd.conf signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Freerunner won't boot: dies in uboot
Am Di 30. Juni 2009 schrieb arne anka: Okay, I don't have the wall charger What may work is this: - press and hold AUX - insert USB power (from a PC) - when the menu comes up, select Power off This should leave the PMU in charging mode. hey! that's quite interesting. could someone put that into the wiki, probably on some kind of first aid page? I'm quite sure it is /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: gsm problem
Am Mi 24. Juni 2009 schrieb Albert Dengg: hi, after i recently upgraded my openmoko gsm firmware to moko11 i got a really strange problem: even though i can make and recieve calls (and send/recieve sms) just fine, i can't get any sound (i don't hear the other side and they don't hear me). before the flashing, it worked (well aside from a differing sound quality expirience). in fear of damaging my gta02 i used the uSD method just to be shure and i got a message that everything went fine. any ideas whats wrong or what i can do change the situation There's no problem known with calypso FW update that could result in broken audio. So I suggest you double-check your SHR rootfs to be correct, esp wrt scenarii files. You might want to call mickeyterm -c aate1 at+clvl=? at+clvl? at+clvl=200 ^d if that doesn't help please log in to the flashing-uSD system via ssh (after the initial flashing finished. you can boot from this uSD a second time without doing any harm). In root's home dir you should find to shellscripts, called sth like flash-moko11 (iirc) and flash-moko8 or sth. you can easily call these scripts to downgrade to a former version of calypso-fw, or even edit to your needs. hth cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [OM2009] Testing 2009-06-11: Misreading hardware clock
Am Sa 13. Juni 2009 schrieb David Fokkema: On Sat, 2009-06-13 at 18:02 +0200, Rask Ingemann Lambertsen wrote: Out of curiosity, I had a look at OM2009: # flash_eraseall /dev/mtd6 # wget --no-verbose \ http://downloads.openmoko.org/distro/testing/daily/NeoFreerunner/fso-paroli-image-om-gta02.jffs2 \ -O - | nandwrite -p /dev/mtd6 - # flash_eraseall /dev/mtd3 # wget --no-verbose \ http://downloads.openmoko.org/distro/testing/daily/NeoFreerunner/uImage-2.6.28-stable+gitr0+f19f259d3c1afde8eae53983fd19f61831927413-r2-om-gta02.bin \ -O - | nandwrite -p /dev/mtd3 - The screen says 16:53 Monday, July 13, 2009. That makes it exactly one month ahead of time. The 2.6.28 kernel needs a backport of these two patches: http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=60c66130a4467ca2a2994a6e3d7d5ac63839eefb http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=cc1663fc922c03feb0d7bbb8b18d62fbac0128de How strange. I've never seen that with Om2009. But, to tell the truth, I'm not using any other distro on my phone. It might be the case that Om2009 gets the current datetime from the GSM network after a few minutes and will set the clock 'correctly' after that. If setting hwclock is done with same month off by 1 algo you use for reading it, you probably only will notice your months have wrong number of days (RTC counting to 31. for July (May?), readout algo says June 31.) /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
Am Mo 8. Juni 2009 schrieb Warren Baird: complained that I sounded a bit muffled, so I reset it to the 101 (same as gsmhandset-a7.state), and since then it seems pretty good - my wife has please notice: http://docs.openmoko.org/trac/ticket/2121#comment:3 gsmhandset-a7.state is deprecated! cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Stylus replacement button cells
Am Mi 3. Juni 2009 schrieb Joachim Ott: The original cells are labeled GP192, searching the web I found equivalent cells labeled LR41 AG3. But when I put 4 of them into the stylus, the laser beam was very weak and became weaker very fast. Is this cell type not suitable for the stylus? I bought this button cells in a set, 6 different types with 6 cells each for just € 3.00, and I tried 3 cells of type LR754 AG5, they work great and the laser beam is as if the stylus was new. Should I put this to the FAQ, and if yes, to which section? Hardware? Misc? A new section Accessoires? Probably your blister pack purchase was aged battery cells (there's a reason those are sold for even 1€ now and then). There's no inherent incompatibility there. Please don't spam wiki with a single random observation. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
Am Do 4. Juni 2009 schrieb William Ray Yeager: A critical friend of mine who has mocked my purchase of an unfinished phone just told me that our connection was as good as a landline! I followed Warren's advice below and lowered control.5 to 80 (I'm naturally conservative) which has (so far) completely removed the previously unbearable buzz my friend had observed on the other end of the conversation. Wow. Now I might not need to solder in a new capacitor! For the demi-newbie: Open /usr/share/openmoko/scenarios/gsmhandset.state Scroll down to control.5 and in that section change the line under 'Mono Playback Volume' from value 110 to value 80. Save file. Call OM skeptic. Gloat. Warren said: I've always had people complain that they got a lot of static when they called me - I thought I had the buzz problem in fact. I just spent the time to figure out how to use alsamixer to tweak things, and if I set control.5 (Mono Playback Volume) to 83 from above 100 like I've seen in other gsmhandset.state files (ranging from 100 to 110 seems normal), I get a perfectly clear signal on the other end. Another unconfirmed taletelling about Buzzfix by ALSA settings. Don't you think we checked this prior to coming up with a hw-rework after months and months of wrestling with this issue? /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
Am Mo 8. Juni 2009 schrieb openm...@humilis.net: Joerg Reisenweber wrote (ao): Am Do 4. Juni 2009 schrieb William Ray Yeager: A critical friend of mine who has mocked my purchase of an unfinished phone just told me that our connection was as good as a landline! I followed Warren's advice below and lowered control.5 to 80 (I'm naturally conservative) which has (so far) completely removed the previously unbearable buzz my friend had observed on the other end of the conversation. Wow. Now I might not need to solder in a new capacitor! For the demi-newbie: Open /usr/share/openmoko/scenarios/gsmhandset.state Scroll down to control.5 and in that section change the line under 'Mono Playback Volume' from value 110 to value 80. Save file. Call OM skeptic. Gloat. Warren said: I've always had people complain that they got a lot of static when they called me - I thought I had the buzz problem in fact. I just spent the time to figure out how to use alsamixer to tweak things, and if I set control.5 (Mono Playback Volume) to 83 from above 100 like I've seen in other gsmhandset.state files (ranging from 100 to 110 seems normal), I get a perfectly clear signal on the other end. Another unconfirmed taletelling about Buzzfix by ALSA settings. Don't you think we checked this prior to coming up with a hw-rework after months and months of wrestling with this issue? Joerg, I also tested this by lowering Mono to 72 with alsa-mixer on my A6 OM2009 Test4 after reading Warrens mail, and I now no longer sound like sitting on a motor lawnmower during a call. Maybe this is something different than the Buzz Issue, but it improves sounds for the other party a lot. This btw is in The Netherlands. After reading that less than 5% of the owners are hit in practice by the Buzz Issue, I was pretty surprised to be one of them. But now it seems the noise is not due to the Buzz Issue? reducing mic gain and/or mic volume might cause some of the many sound improvement circuits involved in carriers' exchange (here: half duplex echo cancellation, kind of a two-way noise gate) to cut out buzz during periods of no voice transmitted. Nevertheless the S/N ratio *during talking* (S=your voice, N=buzz) can NOT be changed by alsa settings any way whatsoever. So this change of control.5 may improve some of the subjective audio sensation for far end, only if you got slight buzz that becomes unnoticeable during actual voice. Severe buzz rendering voice illegible can NOT be cured this way, not even a little bit. btw you can get same result (without lowering volume of your voice for far end, and without relying on carrier's/far-end's EC meassures) by setting AT%N noise gate value of Calypso to a level that effectively stops buzz during periods of no voice (aka silence) Official recommendation is: If you got Buzz issue, try to get bigC-buzzfix. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [om2009-r4] Warren's Settings Worked for Me (was Re: Om2009 testing release 4)
Am Mo 8. Juni 2009 schrieb Risto H. Kurppa: Joerg, I also tested this by lowering Mono to 72 with alsa-mixer on my A6 OM2009 Test4 after reading Warrens mail, and I now no longer sound like sitting on a motor lawnmower during a call. Maybe this is something different than the Buzz Issue, but it improves sounds for the other party a lot. I've experienced that on some settings the background noise of my environment (=cars / computer fan / air conditioning / ...) is amplified a lot when I'm silent and the person I'm talking to can hear it. It isn't easy to recognice what's the source of the noise but I'd say there's some tunign to do to make this work. So I don't think it's the actual buzz but amplifying the environment. r See my other post wrt EC and calypso noisegate. Basically I'm telling your story there. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Qi causes WSOD (was Re: [2008.testing] WSOD)
Am Mi 20. Mai 2009 schrieb Chris Jenks: Apparently the qi version hosted there is mislabeled as 2.6.28, since I checked what got installed and it is indeed 2.6.29-rc2. Errr, Qi-version, kernel version??? /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: OM Freakout
Am Fr 15. Mai 2009 schrieb Sean Chadwell: Just a minute ago, I pushed the power button to wake the phone, and it totally freaked out, making a kind of scratchy buzzing sound and vibrating. The AUX button glowed red and the power button glowed purple. I had to pull the battery. Rebooted without incident. This is a GTA02, with 2008.12 . . . Any ideas what that was about? -Sean possible cause: you accidentally hit/released the AUX button _during_ bootloader startup. As the address switching (from NAND to NOR) done by AUX is direct hw without any buffering, a state-change during load of bootloader (i.e. the first few ms after pressing powerbutton) may mess up the whole system. Result unpredictable. Anyway chances to seriously break anything by such an incident are small to zero (though I'd recommend to pull the battery rather sooner than later to stop the madness) cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: The myth of missed phone calls (was: OM2008.12 - basic usage instructions?)
Am So 3. Mai 2009 schrieb Rask Ingemann Lambertsen: On Sat, May 02, 2009 at 11:10:28AM +0200, Jeffrey Ratcliffe wrote: I have to access the image from somewhere. At 270Mb, it is to big to fit in flash at the same time as an OS. I can't plug in 2 uSDs, USB card reader if you have one. so I would like to mount the directory where the image is stored on the host computer, so that I can dd to the device in /dev One or more of the following ought to do the trick. If you use a USB card reader, it will be /dev/sda instead of /dev/mmcblk0: # wget URL-to-image -O /dev/mmcblk0 # scp location-of-image /dev/mmcblk0 sorry the image is .tgz, so you'll need to pipe it thru tar /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: rmmod
Am Do 30. April 2009 schrieb An@: Hi, i've tried a rmmod snd_soc_neo1973_gta02_wm8753 to have access to the WM8753. But it doesn't work have anyone already tried that command ? What's the meaning of to have access to the WM8753? /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: buzz-fix components
Am So 26. April 2009 schrieb Anthony Winter: It's hard to get surface-mount components individually to solder on and fix the buzz. Is it possible for someone to send me the resistor and capacitor? I've done this multiple times now, for European destinations. If this applies to you, please contact me by PM. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: The myth of missed phone calls (was: OM2008.12 - basic usage instructions?)
Am Do 23. April 2009 schrieb Nicola Mfb: 2009/4/20 Daniel Willmann dan...@totalueberwachung.de: [...] I'm curious, what distro are you using? I would be pretty surprised if carrier differences are having that effect. May the gsm firmware influence that? For sure. MOKO11 fixes the doesn't resume from 1. suspend after GSM powerup issue. We recommend flashing MOKO11 using the uSD method described in http://wiki.openmoko.org/wiki/GSM/Flashing#uSD-card_Image /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: The myth of missed phone calls (was: OM2008.12 - basic usage instructions?)
Am Mo 20. April 2009 schrieb Daniel Willmann: On Tue, 14 Apr 2009 21:51:09 -0400 Paul pault...@gmail.com wrote: On Tue, Apr 14, 2009 at 6:04 PM, Daniel Willmann dan...@totalueberwachung.de wrote: I had to clearify that if there still are problems with incoming calls (which I honestly don't believe) then they are not immediately noticable. While this may be true with your current carrier and phone usage, this is far from the case with my phone. Part of the problem Openmoko as a community is facing is adequate testing. With something as complex as worldwide telephony system, it's the biggest detriment to Openmoko's success. I'm curious, what distro are you using? I would be pretty surprised if carrier differences are having that effect. I second this /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Debug Board] Lauterbach / Trace32 / JTAG
Am Mo 20. April 2009 schrieb J Baart: Hello, I'm currently working on a bootloader for the neo freerunner. I can't get gdb completely working so I'm looking for another way to debug. However I do have a Lauterbach. When I connect the Lauterbach to the 20pin JTAG connector on the debug board (v3) I cannot power on the freerunner. When I connect an usb adapter to power the debug device, the freerunner will power on. I can attach the device with Trace32 but when it tries to bring up the system it gives some error messages like: emulation reset detected. I used a Trace32 file that I downloaded from the Samsung website to do the basic init of the s3c2442 so that shouldn't be the problem. Now I'm not sure if it's possible to use the debug board to connect a Lauterbach. It seems like the pins are connected correctly and I don't think that an external power source should be connected. So my question is: Is there someone out there that got a Lauterbach working in combination with the debug board? Or is there someone that can tell me if it's possible to use a Lauterbach in combination with a debug board. As I get it you're hooking a hw-jtag-debugger (Lauterbach) to the 20pin-post-connector of debug-board to access FR. This connector is not designed to adapt an external jtag-debugger to FR, instead it's supposed usage is to connect other jtag-targets to debug board and use the jtag-USB gate on debug board to run a jtag-sw-debugger controlling either the FR or any of those other jtag-target-devices connected via 20-post. Your connection might fail due to USB-chip creating undefined load on the jtag-lines from Lauterbach to FR. Hope I got it right when trying to understand what you intended to do. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: No GSM. Suspect dead Calypso. What to do?
Am So 12. April 2009 schrieb danek: On Sun, 2009-04-12 at 06:05 +0100, Joerg Reisenweber wrote: Give r...@om-gta02:~# mickeyterm -c All this on GSM-flashing uSD-image booted from uSD, login via ssh. you might want to r...@om-gta02:~# ps x 1645 ?S 0:00 /bin/sh /etc/rc5.d/S99flash-moko start r...@om-gta02:~# kill 1645 to stop the gsm-flashing process (if you're sure FLUID isn't just about to flash the GSM-FW. I.e: if it shows either Bootloader: (reset target) or Program: (0 sectors, 0*8k=0k) () ok it's absolutely safe to kill the flashing process) Thanks, I will try the GSM-flash uSD image and mickeyterm. And if you agree, I think it's probably safest to stop the flashing process by removing S99flash-moko from /etc/rc5.d ... Sure. The perfect way. If you are familiar with electronics you also could test the bat by probing for voltage and temporarily attaching a 1R2..1R5 (0.5W! better a 2W) during watching the voltage. (0.5sec). Or use a incandescent lightbulb that's drawing ~2A @ 3V5, instead of the resistor. You probably need a fast DVM or an analog voltmeter or 'scope for this. Bat voltage must not drop below say 3V. Well testing with a spare bat for sure is much simpler and yields more reliable results anyway. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO] FSO unfunded?
Am Mi 8. April 2009 schrieb Craig Woodward: What does this mean? That FIC/OM don't have anyone working on it anymore? FIC isn't OM! /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
Am Mi 8. April 2009 schrieb Nicola Mfb: Suppose now that tangoGPS or navit, or other gps tools may do simply a couple of call to org.freesmartphone.Usage.RequestResource at startup, when the application exits the fso daemon automagically releases the resources: you obtain a on-click-and-do-not-suspend-dim-navigation-system-restoring-all-at-exit :)) please see and support http://trac.freesmartphone.org/ticket/393 /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Call volume
Am Mi 8. April 2009 schrieb bburde...@comcast.net: Hi all; With SHR-testing the phone seems to be fairly usable. Battery life is even pretty decent. However, one thing that is a dealbreaker for me as far as using my freerunner as my main phone is the call volume. I can make calls just fine from my living room, but in a noisy cafe or inside a car I can't hear very well at all. I've adjusted the volume before from text config files, but you walk the line between usable call volume and bad echo problems for whoever you're talking to. Has anyone been able to address this for themselves? This is maybe the last major issue that keeps the FR from being my main phone. But unless this is addressed I can't really recommend the phone to anyone but hobbyists. Despite everybody else in this thread answered on how to adjust earpiece level, I get it your real problem is echo. please look here: http://wiki.openmoko.org/wiki/Neo_1973_and_Neo_FreeRunner_gsm_modem#Eliminating_echo_on_the_non-neo_end_.28far_end.29_of_phone_calls /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: No GSM. Suspect dead Calypso. What to do?
Am Sa 11. April 2009 schrieb Timo Juhani Lindfors: danek dan...@digsoc.com writes: 4. Since it took a while to get socat sorted, and I wasn't sure what you meant when you said Calypso goes to sleep very fast (goes to sleep after being powered on? in between commands? didn't know.) I If you give a pause when entering the commands it sleeps. The next command will then wake it up but it won't parse that first command. Give r...@om-gta02:~# mickeyterm -c --- Mickey's Term V2.9.1 @ /dev/pts/1 --- AT-Command Interpreter ready ATE1 (((this one invisible, you need to type blind. repeat if you don't get OK))) OK at%sleep=1 EXT: I OK ATE1 is enabling instant echo from calypso, which I find much more convenient (same as the char-wise input by -c parameter to mickeyterm) at%sleep=1 stops the annoying 10sec timeout that makes you enter every command twice. All this on GSM-flashing uSD-image booted from uSD, login via ssh. you might want to r...@om-gta02:~# ps x 1645 ?S 0:00 /bin/sh /etc/rc5.d/S99flash-moko start r...@om-gta02:~# kill 1645 to stop the gsm-flashing process (if you're sure FLUID isn't just about to flash the GSM-FW. I.e: if it shows either Bootloader: (reset target) or Program: (0 sectors, 0*8k=0k) () ok it's absolutely safe to kill the flashing process) Everything looks normal here except the reset. Can you double check that you don't have any other software that could write to the power_on (or pwron) node of gsm in /sys? If this indeed is a real reboot of the calypso chip then we'd really like to see calypso debug output (you need to construct a cable to capture it, do you have electronics experience?). Me: ATD+1XXXYYY // this is a US telephone number, phone sitting next to me Yeah after reset it obviously looses registration to network. I really wonder whether your battery is ok. You know modem is powered from battery and when it starts to transmit for registering to the network it demands quite some power from bat that can't be provided by bat-charger chip PMU. So it's very likely modem would reset due to brownout as soon as it tries to register to network. Please try and find a spare bat (see wiki for compatible bat e.g. from nokia if you can't manage to get a GTA02-bat). See if modem behaviour changes significantly with new bat. I'm really sorry you have such an extended period of problems with your FR's modem. Hope we will track it down now. HTH cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: No GSM. Suspect dead Calypso. What to do?
Am So 12. April 2009 schrieb danek: You need a 2.5mm 3-pole plug and then something to listen to the 115200 8N1 serial data coming the middle pole. This is 0..3V so you Please DO NOT quote msgs without clearly marking them as quote (e.g. like above) I skip absolutely every msg I encounter that is fooling me like this. Thanks /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Fwd: Re: Seal neo again
[on behalf of David] ---BeginMessage--- Joerg can you be so kind of forward this message to the support list, In spite I'm suscribed It doesn't me allow to post, I have report a message to list administrator 2009/4/2 David Reyes Samblas Martinez da...@tuxbrain.com: Joerg is no matter to automatic deny anything in the on broken seal, I have assumed warranties with this seal broken without problem and encorage those feeling confidence to repair little issues like a blocked earphones switch or if they just want to take a look or connect something on the internal connectors, etc, etc. Is about information information to speed up things in case costumer use their warranty, if the seal is not broken you almost know nobody ,in this case anybody else but my technician, has messed with internals so you have one thing less to worry about. Dealing with this kind on openess in hardware and warranty is new to any distributor you may ask , and anything than can easy things like a silly sticker are welcome. Also it has a social function :) , costumers tend to aks before breaking the seal so this lead me the oportunity to asses him in whatever he has in mind or derivate to a costumer that previously succeed in they tend to do. I will deal warranties in case by case basis as I do now a days no intention to use it as excuse to avoid it at all. 2009/4/2 Joerg Reisenweber jo...@openmoko.org: Am Do 2. April 2009 schrieb Steve Mosher: Not sure what you are talking about exactly David Reyes Samblas Martinez wrote: We need you provide us seal stickers like neo has in the srcrew to know if case has been reopened after a succesfull fix there's a silly whitered-cross paper label sticky sealing one of the screws on FR. I never got it what's the purpose of this seal. Especially as FR owners are supposed and even encouraged to open those screws to attach a debugboard, and consequentially there's no loss of warranty resulting from doing so. (btw that's absolutely no difference to jurisdiction about arbitrary desktop PCs which as well are perfectly legal to open and insert some extension PCI-card, without creating any reason for the seller to deny lawfull warranty no matter how many warranty void if seal is broken stickers he might attach to the PC) cheers jOERG -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, GP2X the Wiz, Letux 400, Arduino Hey, watch out!!! There's a linux in your pocket!!! -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, GP2X the Wiz, Letux 400, Arduino Hey, watch out!!! There's a linux in your pocket!!! ---End Message--- signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Seal neo again
Am Do 2. April 2009 schrieb Steve Mosher: Not sure what you are talking about exactly David Reyes Samblas Martinez wrote: We need you provide us seal stickers like neo has in the srcrew to know if case has been reopened after a succesfull fix there's a silly whitered-cross paper label sticky sealing one of the screws on FR. I never got it what's the purpose of this seal. Especially as FR owners are supposed and even encouraged to open those screws to attach a debugboard, and consequentially there's no loss of warranty resulting from doing so. (btw that's absolutely no difference to jurisdiction about arbitrary desktop PCs which as well are perfectly legal to open and insert some extension PCI-card, without creating any reason for the seller to deny lawfull warranty no matter how many warranty void if seal is broken stickers he might attach to the PC) cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Bluetooth busted (Was: [HW] Ear phones with microphone, for hands-free calling?)
Sorry, this whole pile of rant is mostly completely incorrect. The remarks about debug-tool that runs on a certain linux release reveal the value of the whole message as well as the competence of OP. /j Am Mo 30. März 2009 schrieb Craig Woodward: This is one of the major things holding me back from using the FR. The shape of it is clunky at best, and add the super low volume you need to run the earpiece at to NOT get echo in the mic and it's useless without a headset. That's assuming you can get it to work as a phone to start with. Most images still can't reliably do that, even with suspend turned off. Having bluetooth connectivity would be great, but that's busted too. As of a couple months ago (when I last tested) _none_ of the images out there could handle bluetooth audio correctly for calls. To pair the device you often have to enter it by hand into a config file, and run a script to connect it, since GUI scanning and pairing is busted in all images. For some images you have to alter another set of config files so sound IO routes to the device (also not a simple task). And after all that, when making a call something always goes wrong. Either you get no audio at all or you get a couple seconds of audio/static and a kernel panic. I tried this with at least 5 different images (2009.12, SHR, FDOM, QT, Debain) and 4 different headsets, all of which work with 2 other phones AND my desktop PC. Right now the only image I've found with good call reliability is Android, but that has it's own issues since it really wants a hardware keyboard. Unfortunately this means for the few images that have bluetooth support, you have to go in with the debug tool to add a default password. I can't do that right now since it requires a linux box with a certain release to run the debug software, which I don't have the time or hardware to setup right now. And FYI: Good luck selling to anyone out there thinking of getting out of the pool. I put my phone (plus stand alone charger, gps antenna, 4G card w/ reader spare battery) up on Ebay shortly after my group mailing a couple months ago. I stated it at $100 with a $250 reserve, it got a few bids but didn't even get close to the reserve. Just what I figured would happen: expensive device that's not usable as a daily phone and now has little to no value. The whole project (FIC, OpenMoko, et al) has such a bad rep that nobody wants a FreeRunner now, even at a discounted price. In the future I'll stick to semi-open devices for phones Unless it comes with some reasonable guarantee that it's going to actually WORK in the way it says it will *at the time of purchase*. I should have returned the phone and reversed charges the first week I got it when it didn't work as simple phone out of the box. (Since it WAS advertised as a consumer ready phone when I purchased mine about a year ago, before FIC/OM updated their web pages to re-tag it as a developer phone.) signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Device somehow powered down - would not power up again
FR is not expected to work without battery. That's technically impossible basically. GSM will take 2A in spikes, and usb can deliver max 500mA, from wallcharger FR may accept up to 1A. As soon as system power consumption gets higher than what USB can deliver, FR is powering down of course. The issues you mentioned were about ability to charge an empty battery, just *because* you need a certain amount of power from bat while booting/operating the device. Probably your assumption about charge state of bat were incorrect, and bat simply run flat so FR stopped working. Please refer to wiki about (empty) battery /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [HW] SIM card mount could use redesign (or better docs)
Am Sa 28. März 2009 schrieb Esben Stien: Toni Mueller supp...@oeko.net writes: I'd like to suggest that the cover for the SIM card gets overhauled, too [..] it looks like short-circuiting the eight contacts unless a SIM card is inserted Maybe this is related to the fried FR reported some days ago;). No it's not /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [HW] microSD card mount needs redesign
Am Mi 25. März 2009 schrieb Johny Tenfinger: Heh, I'm wondering... What's wrong with me, if I can remove SD card from FR's reader easily without any tools, handles or hacks? ;) SD-mounts are very different on holding force from device to device. /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [HW] microSD card mount needs redesign
Am Mi 25. März 2009 schrieb xChris: As you can have a live system running from the uSD, I don't think its was a good idea for the Openmoko to have a uSD slot that would allow removal/insertion without shutting down the FR... Don't you think removing the card would shut down Neo reliably then? ;-) As does removing the battery. /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Help! GSM not working after updating to SHR (was: Moko10)
Am Fr 27. Februar 2009 schrieb Ingvaldur Sigurjonsson: Me too is in the same boat. After having the Freerunner laying around, untouched, for quite some time I decided to give it a new chance so I started doing some upgrades. I also followed the wiki on flashing the GSM but I never got the (fluid, version 3) ok. Been trying with flashing different kernels/rootfs's to no avail. I cant even get to the phone over USB anymore. Now the Phone is completely bricked. Does anyone know how to unbrick the phone ? A method using debug board maybe ? Regards - Ingi M. K. Pkhetan wrote: Hi everybody, I really appreciate your help because my phone is not any more a phone!! the story is that i have updated the GSM firmware to the Moko10 in my GTA2Bv5 as described on http://wiki.openmoko.org/wiki/GSM/Flashing I have follow exactly the instructions there on the same proposed FSO, and every thing went ok, i even got the message : (fluid, version 3) ok Checksumming (269 * 8kB = 2152kB): ok Flash Detect: (0xEC, 0x22A0) Samsung K5A3240CT ok Program: (34 sectors, 267*8k=2136k) (***) ok so every thing seemed ok i even tried the proposed verification : r...@om-gta02:~# cat /dev/ttySAC0 r...@om-gta02:~# echo -en 'AT\r' /dev/ttySAC0 r...@om-gta02:~# echo -en 'AT+CGMR\r' /dev/ttySAC0 +CGMR: HW: GTA, GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal_amd8_ts0-Moko10 kill %1 Well, after that i went back to SHR testing, but i couldn't register to the GSM network. i tried FDOM and same thing : no registering Then i said maybe the firmware is not valid (even that i ckecked the md5sum and it was ok) so i tried to downgrade to Moko8 (the gta02bv5 one) but i stucked in Bootloader: (reset target) i tried the -oO and -oo. with and without the 'FLUID_FLOWCONTROL=h' and in the other season i tried the s3c24xx-gpio b7=1, echo 0 /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on and echo 1 /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on but nothing work i can't reflash my GSM anymore Please notice all this turned out to be a problem of Qi and kernel (here SHR-testing) combination, and problem with GSM has been existing prior to successful GSM-flashing. It's not related to GSM-flashing in the way OP suggests! Also it's absolutely unnecessary to use devirginator and debug-board to recover from this QI+kernel issue leaving GSM serial interface in an unusable state. Usual bootloader and/or kernel update following standard dfu-util path will suffice, as mentioned by Arne and Al in previous posts. OP asked for a method to unbrick FR and that's the advice Werner gave. Nevertheless OP's FR never has been bricked, and usage of devirginator or the dynpart/dynenv isn't recommended for a standard procedure. There's no way to brick FR by flashing GSM. /jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: WSOD solutions??
Am Mi 3. Dezember 2008 schrieb Ruediger Helge Wolf: Hi... [WSOD] FYI: Harald Welte (the original author of this code) suspects this to be a timing problem / command ordering problem when reenabling the display. I have a device that exposes this problem at runtime which he's going to inspect on the 27th of this month. Any news? Anything we can help with? Further investigations? What about the FIC guys, do they know about the issue? We are aware of the problem. Last few days we did all sorts of timing tweaking inside driver, to the extent of lowering SPI-CLOCK, and compared datasheet of JBT6K74 with timing setup in driver. Impact on WSOD was nonexistent. Command ordering seems a somewhat less probable source of this issue, as it's the same that is executed on device-init during boot and we don't see any WSOD there. Also command ordering isn't very likely to yield random result, like we see in WSOD issue. Futher findings: The problem seems to be specific to the particular LCM, as swapping the LCM of a device with 95% WSOD resulted in 40 consecutive resumes without WSOD. The no deep_suspend patch didn't work for us - it's a problem often triggered by but not directly caused by deep_suspend. Further plans: modify driver to take down the complete LCM via LDO6 instead of entering deep_suspend. This seems to be the more reasonable approach for saving power while LCM disabled anyway, and it might cure WSOD as the LCM is powered up from suspend-mode the same way as on boot. Side-effects still under investigation (sneak currents, any persistent data lost during power down, timing issues for LCM coming up) cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sad Story
Please move to [community] this is he SUPPORT-ML! /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: why is my freerunner magnetic?
Am Di 2. Dezember 2008 schrieb Joel Newkirk: On Tue, 2 Dec 2008 17:59:34 +1300, Robin Paulson [EMAIL PROTECTED] wrote: this probably seems like an odd question, but why does metallic stuff stick to the back of my freerunner? i noticed yesterday, that it had picked up a usb connector that was lying next to it. it wasn't near the speaker, so i know it's not the magnet in that. the area in question is directly behind the battery connectors (i.e. away from the battery), pretty much behind the bottom-left corner of the screen, and is about 30mm x 30mm. it's more noticeable with the back taken off There are two speakers, you know... ;) NOPE /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: WSOD solutions??
Am Do 4. Dezember 2008 schrieb Andy Green: Somebody in the thread at some point said: | Further plans: modify driver to take down the complete LCM via LDO6 instead of | entering deep_suspend. This seems to be the more reasonable approach for | saving power while LCM disabled anyway, and it might cure WSOD as the LCM is | powered up from suspend-mode the same way as on boot. Side-effects still | under investigation (sneak currents, any persistent data lost during power | down, timing issues for LCM coming up) Any reason none of this is on the Trac report? We decide on when to post any results to Trac. Emphasis on results. The hard reset line we operate into the LCM should make whether the power to it is up in suspend moot... neither does it explain why the WSOD comes with the blanking changes that are nothing to do with suspend. Thanks for concise summary of obvious conclusions resulting from my previous posting. /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: My Mickeyterm/Ctrl-z Headache
Ctrl-D is a shortcut for exit *only* when given at start of line. Generally Ctrl-D is ETX what's exactly what I would expect for end of SMS /j Am So 30. November 2008 schrieb VictorSigma: CTRL-D is to terminate out of mickeyterm and cant be used to signal out of sms. Joachim Ott-2 wrote: 2008/11/29 VictorSigma [EMAIL PROTECTED] I am using the FSO release. I have been able to ssh into the phone and with mickeyterm able to send AT commands to read and delete SMS messages. The problem is that when I try to send a SMS message you must hit CTRL-Z to signal the termination of the message. This is also the command to pause a command in FSO and it won't allow me terminate the message. Is there anyway to get around this? Has anyone been able to send a SMS message via shell using mickeyterm? Are you sure that it's not Ctrl-d to signal termination? Ctrl-z was it in good old msdos. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support -- View this message in context: http://n2.nabble.com/My-Mickeyterm-Ctrl-z-Headache-tp1593123p1594265.html Sent from the Openmoko Support mailing list archive at Nabble.com. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: gta02, 2007.2: frequent wakeups -- creating workaround
Am Mi 13. August 2008 schrieb arne anka: I finally got around to checking this. The script runs instantly when I have cell registration. So, that explains why my script was taking so long. But what can I do about it? you could check if you have registration, someway along echo -n csr | libgsmd-tool -m shell and read the return. If I've suspended my Neo, I wouldn't want it waking up (and corrupting the SD card) as soon as I move into a cell tower's range... it's worth mentioning that running GSM without association to a network probably drains battery like hell, as GSM-chipsets tend to constantly search the whole frequency range for some BS to register. I've experienced factor 5 to 10 for power consumption. /jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: USB networking in Ubuntu
Am Mo 4. August 2008 schrieb Olivier Berger: Joerg Reisenweber [EMAIL PROTECTED] writes: Am So 3. August 2008 schrieb sparky mat: Flushed '-t filter'. Added MASQUERADE-ing as per the wiki. It worked. Finally, my TangoGPS can download maps :P On Sat, Aug 2, 2008 at 11:50 PM, sparky mat [EMAIL PROTECTED] wrote: On Sat, Aug 2, 2008 at 11:45 PM, sparky mat [EMAIL PROTECTED] wrote: I am not sure what I did (though it seems like ifconfig usb0 192.168.0.200 followed by ifconfig usb0 192.168.0.202) but it works now!! I can ssh in :D .. Ok.. now for some MASQUERADE-ing Stopped working. It's something to do with my iptables. Figuring it out. Please note there's an issue with uboot breaking usb for 50% of the boots. so if it doesn't work, a simple reboot of FR might change it. Refer to Andy's postings of last 48h on this issue. Thanks for that information. However, a proper link would have been useful :-( Maybe : http://lists.openmoko.org/pipermail/support/2008-August/000912.html ? Best regards, Maybe just adding the link by yourself would have been enough :-( My job is to fix your hw and create new one, not to supply links. C'mon encourage me to give such information in the future, when I come along. Best regards jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Buzzing sound
Am Di 5. August 2008 schrieb Jeffrey Ratcliffe: 2008/8/5 Joerg Reisenweber [EMAIL PROTECTED]: Only thing you may try for now is changing GSM-provider, as it seems to be very clear the issue is to be found on some GSM-networks, and not (or less) on some others. Generally the 1800/1900 networks seem to be more likely to cause this problem than the 850/900 networks. For Germany I got reports f noise only for E+ network (and resellers) My experience on Blau (E+) is that I hear the caller excellently - but the caller complains that buzzing is very bad. Hard to tell. We don't get sufficient number of reports, and due to nature of reports nearly all are problem-reports, people without problems usually don't post a report. I suggest, therefore, a wiki page where users are encouraged to document the line quality at both ends (good or bad) against their provider. Local has never been a related issue. It's always far end that get's the buzz. Quite basic and important to understand. We have *two* distinct audio-transfers with opposite directions. Buzz is on FR-(mixer,GSM)-far_end only. If you hear local buzz, your mixer/gsm-sidetone settings are somewhat incorrect. I'd appreciate such a wikipage and the reports there very much. Additional needed info: GSM-band (we don't know all providers!), signal-level GSM In fact that's what I did in Germany, collect reports from users about noise. I even had them call my answering machine so I actually collected some real audio samples as *.wav. Result: in Germany it's virtually only E+ that's causing the noise. Anyway still this makes no database for a guess on percentage of users that suffer from complaints of their callees about buzz-noise. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Buzzing sound
Am Di 5. August 2008 schrieb Sebastien Nanchen: Hello, I played with my Freerunner for some days now. I am part of the users who have the buzzing sound problem. I modified the sound configuration as described in the wiki and was able to eradicate the echo (caller-side) and to make the low-level voice volume (called-side) acceptable. Fine! :-) But the buzzing sound stays and make the FR unusable as a phone (I tried both OM 2007.2 and the latest image of Qtopia). The GSM-buzz-noise issue isn't related to image used. At least that's what we think of it at the moment. It's a hw-issue. (Please note we fixed other hw-issues by sw-patch - compare sd-card/GPS). Anyway there's no *bug* in any of the sw-stacks/images that causes this issue, so changing image won't help, until we eventually might find a sw-fix for the hw-issue. I know this was much discussed in the ML, and I'm sorry to come with this topic again, but I haven't found any answer yet. There isn't any yet. My regret :.( I would know if y missed some important information about a tweak solving this issue? Only thing you may try for now is changing GSM-provider, as it seems to be very clear the issue is to be found on some GSM-networks, and not (or less) on some others. Generally the 1800/1900 networks seem to be more likely to cause this problem than the 850/900 networks. For Germany I got reports f noise only for E+ network (and resellers) If not, does somebody have an idea about how many users are experiencing the same problem (10%, 30%, more?) Hard to tell. We don't get sufficient number of reports, and due to nature of reports nearly all are problem-reports, people without problems usually don't post a report. Is there any hope we can use our freed phone as a phone in a foreseeable future? See above... Investigation on issue continues. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Buzzing sound
Am Di 5. August 2008 schrieb Jeffrey Ratcliffe: 2008/8/5 Andy Green [EMAIL PROTECTED]: Like Ole says when I started looking at it, by calling a landline in the same room and listening to its receiver lying on the desk, it varied tremendously and not in a repeatable way. Eg, it appeared to vary by orientation of the phone, but when I traced the path backwards, the buzz did not return. OK. Confirming this - the buzzing seems to come and go in waves of varying frequency. Even without touching the phone, the buzzing just comes and goes. I noticed the buzz come and go in discrete steps. I guess that's basestation sending PCF commands to mobile, to level up/down the TX-power. BS decides on this depending on signal-quality of MS as BS sees it. It would be *very* helpful to confirm this, by using some RF-meter (e.g. microwave leakage tester?), and/or reading the battery current, while observing the noise come and go- Also, I had to keep whistling during this to provoke transmission actions that seem to be the start of the issue. You obviously need a signal generator for repeatability - unless you have perfect pitch... Nah, that's just to give some data to GSM-chip it has to transmit. Otherwise it will enter dicontinuous transmission mode, means simply stopping to transmit as there's nothing but silence we had to send to the other end. So the actual pitch is irrelevant. Any kind of noise will do, as long as it's loud enough. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Buzzing sound
Am Di 5. August 2008 schrieb Andy Green: Somebody in the thread at some point said: | So it comes and goes in discrete steps and it lags behind the change of | position. | | That's exactly the behaviour we would expect when noise is related to | MS-TXPower controlled by a PCL command from BS. BS isn't responding to any | momentary change in signal-strength of inbound MS-signal, instead BS does Sounds good. Just a note, on the skelephone that I use I replaced the GSM antenna with a short length of patch wire, it still works (and some guy was complaining normal GTA02 is for hardcore hackers). I guess if I shortened it further, it can force base station to tell me to use max power all the time. RF performance seems fine with $WIRE like 5cm long. When shorting the wire, we reduce antenna gain. This basically means we need more power from battery, to have the same RF signal strength. So yes, probably BS would level up the PCF, but only to the point where we have same local RF field around GTA02. As noise is supposed to be introduced to GTA02 by own (and externally applied) RF, and not by battery current LF/DC, the only effect would be a reduced battery life time. In fact it's the SWR [http://en.wikipedia.org/wiki/Standing_wave_ratio] that gets worse when creating a impedance missmatch by shortening antenna, so a part of the RF-power is reflected at antenna rot point and fed back to amplifier and dissipated producing heat. Depending on power and design of last amplifier stage this can even burn out the amplifier. Of course reducing the antenna gain is a little bit like flashing another power class to the firmware, in that it limits the maximum effective RF power the device can emit. So maybe this could be one of the possible fixes for this issue (a very nasty one, that probably even won't yield the desired results) to reduce gain by crippling the built-in antenna. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Buzzing sound
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. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Battery discharging after long time connected to the power charger ?
Please note: 1) Openmoko does NOT recommend to do this, nor is it usually necessary when using the OM-charger or a standard powered host at PC. It's a hack for non-OM wallchargers only. 2) there already is such an app. Please search the wiki for it! /jOERG Am Di 29. Juli 2008 schrieb Angus Ainslie: I got tired of forcing the charge from the command line. I wrote a python app to view and control the charge current. You need to opkg install python-pygtk python-pygobject and your kernel needs to have the force_usb_limit_dangerous patch. copy http://www.handheldshell.com/software/power_center into /usr/bin and chmod u+x /usr/bin/power_center copy http://www.handheldshell.com/software/power_center into /usr/share/applications To enable fast 500 mA charge touch /home/root/allow_force_500 To enable fast 1000 mA charge touch /home/root/allow_force_1000 I don't recommend using this one The home page is here http://www.handheldshell.com/software/powercenter.php Angus signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: OM2007.2 continuously freezes!
Am Mo 28. Juli 2008 schrieb Marco Trevisan (Treviño): Joerg Reisenweber wrote: Am Mo 28. Juli 2008 schrieb Marco Trevisan (Treviño): I should say that my very first Freerunner experience was not so correct since as soon as I've connected it to my wall charger for it's first recharge, it powered on (also if I didn't press the power button before). Since the 1A current rate should be enough both to run it and to charge the battery, I didn't powered it off. Please note the many statements about the need to completely boot up the device to charge battery, to be found spread all over the MLs. Mh what you mean? That I should have had turn my FR immediately off, or that I've not made a bad thing? When you plug in charger, Neo *has* to boot up. Then it will charge. That's been discussed really exhausting now. BTW: please don't send me HTML-mails! Stating you care about format :-D cheers jOERG signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Keep losing sound
Am Fr 25. Juli 2008 schrieb shawn sullivan: I keep losing sound on my FR after a few days. This effects the ringing and the normal system sounds. I can still hear a phone call conversation though. When I flash to a new build, the sound comes back and works for a few days, then stops working. i've checked my alsamixer and the headphone and PCM volumes are up. What else am I missing? comare files */scenarios/*.state with those in original image (*.tar.gz) probably those files are restored to mixer whenever a call comes in, and what you are checking might be the default that's not the same as during call. /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Charging nokia batteries with the freerunner
Am So 20. Juli 2008 schrieb Russell Sears: Is it OK to charge nokia BL-5C batteries with the freerunner? Will I run into nasty problems if I charge the Nokia battery with the Freerunner? I'm worried it will overcharge the battery and/or be a fire hazard. I've heard that nokia chargers that charge 5-BL(?) type batteries can charge the FIC freerunner battery. No problem /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
