Re: How to get serial port connection to Neo Freerunner? / SOLVED
On Monday 04 April 2011, Dave Schmidt wrote: > Hi Al and the list, > > > From: Al Johnson on 03/29/11 03:17 PM > > > > Am I right in thinking you're using the debug board to get a serial port > > level shifted to 3.3V, and connecting that to the Calypso serial > > interface through the headset jack? > > No... I do not fully understand your question, which probably means > I'm not trying THAT :) > > What I understand now, is that for my purpose (running osmocon on > the phone) serial connection is not needed, as in OpenMoko case the > communication happens via TCP socket as explained in > http://bb.osmocom.org/trac/wiki/OpenMoko . Thanks anyway! The Calypso in the OpenMokos has two serial interfaces. One is connected to the cpu and appears as /dev/ttySAC0, and the other is connected to the headset jack socket. According to their wiki[1][2] osmocon connects to the calypso through either of these serial ports, and provides a socket interface. If you run osmocon on the phone the obvious port to use is /dev/ttySAC0. If you were running osmocon on a separate machine you would connect via the headphone jack instead, just as you would for most of the other supported handsets[3]. The debug board contains a USB serial interface that can be used to connect to the headset jack socket[4], so when you mentioned the debug board I assumed you were using this method. [1] http://bb.osmocom.org/trac/wiki/osmocon [2] http://bb.osmocom.org/trac/wiki/CalypsoRomloader [3] http://bb.osmocom.org/trac/wiki/CalypsoSerialCable [4] http://lists.openmoko.org/pipermail/hardware/2009-April/001109.html ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: How to get serial port connection to Neo Freerunner? / SOLVED
Am I right in thinking you're using the debug board to get a serial port level shifted to 3.3V, and connecting that to the Calypso serial interface through the headset jack? On Tuesday 29 March 2011, Dave Schmidt wrote: > ...and sorry for not being able to send email neither, > > > Answer found, sorry for doing it only AFTER posting :) > > I am (was) missing the debug board and > > and ftdi_sio module. > > After doing > > sudo rmmod ftdi_sio > sudo modprobe ftdi_sio vendor=0x1457 product=0x5118 > > the debugging board is recognized: > > ftdi_sio 2-2.1:1.1: FTDI USB Serial Device converter detected > usb 2-2.1: Detected FT2232C > usb 2-2.1: Number of endpoints 2 > usb 2-2.1: Endpoint 1 MaxPacketSize 64 > usb 2-2.1: Endpoint 2 MaxPacketSize 64 > usb 2-2.1: Setting MaxPacketSize 64 > usb 2-2.1: FTDI USB Serial Device converter now attached to ttyUSB0 > > Thanks for patience! :) > > D. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: How to reset the screen through command?
On Thursday 10 February 2011, dukelec wrote: > duke@dukelec:~$ ssh root@192.168.0.202 > root@om-gta02 ~ # export DISPLAY=:0 > root@om-gta02 ~ # echo "qvga-normal" > /sys/bus/spi/devices/spi2.0/state > -sh: can't create /sys/bus/spi/devices/spi2.0/state: nonexistent directory > root@om-gta02 ~ # echo "normal" > /sys/bus/spi/devices/spi2.0/state > -sh: can't create /sys/bus/spi/devices/spi2.0/state: nonexistent directory > root@om-gta02 ~ # xrandr -s 480*640 > Size index 480 is too large, there are only 3 sizes > root@om-gta02 ~ # > > I need more help. close to success ... Correct your typo in the xrandr line. You have * in place of x. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Battery discharges when not in use.
On Saturday 24 July 2010, Πρεκατές Αλέξανδρος wrote: > στις 24/07/2010 08:41 πμ, O/H Al Johnson έγραψε: > > On Saturday 24 July 2010, Πρεκατές Αλέξανδρος wrote: > >> Hi. > >> > >> I noticed that when my GTA02v6 neo is powered off > >> after some days i cant open it again, so i assume that > >> battery dried out. > >> > >> Is that a hardware issue or i have a bad battery. > > > > How many is 'some'? The GSM hardware is connected directly to the battery > > iirc, so it is possible there is a small drain there even when the phone > > is turned off. I know that with the GSM turned off I can leave it > > suspended for a week and still have plenty of charge left when it > > resumes, but I don't remember anyone looking at how long it could last > > with the power off. > > I had it turned off for 8-9 days. > i tryed the http://wiki.openmoko.org/wiki/1024 test script > > r...@om-gta02 ~ $ deep-sleep-check.py > dsc.log > and ctrl+c in 1 minute . (does it terminate?). > I dont get any output so i mustnot have the bug. If you had it turned off this bug wouldn't be a problem anyway. If you had it suspended then this bug or its workaround (disable deep sleep) will reduce battery life, but even without this bug maximum standby time with gsm enabled is ~140hrs. > Is there any clock draining power ? how does gtm02 keep time? ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Battery discharges when not in use.
On Saturday 24 July 2010, Πρεκατές Αλέξανδρος wrote: > Hi. > > I noticed that when my GTA02v6 neo is powered off > after some days i cant open it again, so i assume that > battery dried out. > > Is that a hardware issue or i have a bad battery. How many is 'some'? The GSM hardware is connected directly to the battery iirc, so it is possible there is a small drain there even when the phone is turned off. I know that with the GSM turned off I can leave it suspended for a week and still have plenty of charge left when it resumes, but I don't remember anyone looking at how long it could last with the power off. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: GPS stopped working, can't figure it out... what else?
On Monday 12 July 2010, Yaroslav Halchenko wrote: > On Mon, 12 Jul 2010, Al Johnson wrote: > > fso-gpsd is a level removed from the gps, so isn't much use for > > debugging. You need to look at the debug output from ogpsd, or disable > > ogpsd entirely and > > here is the excerpt from the log... not sure why it says that serial is > closed... > > and and configuration I had > [ogpsd] > # possible options are NMEADevice, UBXDevice, GTA02Device, EtenDevice > device = GTA02Device > #device = UBXDevice # this like I added ... > # possible options are SerialChannel, GllinChannel, UDPChannel, FileChannel > channel = SerialChannel > # For UDPChannel the path defines the port to listen to > path = /dev/ttySAC1 > > > r...@om-gta02 /var/volatile/log # grep gpsd frameworkd.log > 2010.07.12 13:03:32.957 frameworkd.controller DEBUGsetting logger for > ogpsd to 10 2010.07.12 13:03:33.86 frameworkd.controller DEBUGsetting > logger for ogpsd.factory to 10 2010.07.12 13:03:34.549 > frameworkd.controller INFO launching internal subsystem ogpsd > 2010.07.12 13:03:34.555 frameworkd.subsystem DEBUGsubsystem ogpsd > created 2010.07.12 13:03:34.624 frameworkd.subsystem INFO Scanned > subsystem via method 'auto', result is ['om.py', 'gpsdevice.py', > 'helpers.py', 'eten.pyo', 'helpers.pyo', 'eten.py', 'ubx.pyo', > 'gpschannel.pyo', 'gpschannel.py', '__init__.py', 'nmea.py', 'om.pyo', > 'factory.pyo', 'nmea.pyo', '__init__.pyo', 'ubx.py', 'factory.py', > 'gpsdevice.pyo'] 2010.07.12 13:03:35.140 frameworkd.subsystem DEBUG > ...in subsystem ogpsd: found module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/om.pyo'> > 2010.07.12 13:03:35.147 frameworkd.subsystem DEBUGno plugin: factory > function not found in module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/om.pyo'> > 2010.07.12 13:03:35.160 frameworkd.subsystem DEBUG...in subsystem > ogpsd: found module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/gpsdevice.pyo > '> 2010.07.12 13:03:35.167 frameworkd.subsystem DEBUGno plugin: factory > function not found in module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/gpsdevice.pyo > '> 2010.07.12 13:03:35.175 frameworkd.subsystem DEBUG...in subsystem > ogpsd: found module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/helpers.pyo'> > 2010.07.12 13:03:35.182 frameworkd.subsystem DEBUGno plugin: factory > function not found in module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/helpers.pyo'> > 2010.07.12 13:03:35.238 frameworkd.subsystem DEBUG...in subsystem > ogpsd: found module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/eten.pyo'> > 2010.07.12 13:03:35.245 frameworkd.subsystem DEBUGno plugin: factory > function not found in module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/eten.pyo'> > 2010.07.12 13:03:35.383 frameworkd.subsystem DEBUG...in subsystem > ogpsd: found module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/gpschannel.py > o'> 2010.07.12 13:03:35.390 frameworkd.subsystem DEBUGno plugin: > factory function not found in module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/gpschannel.py > o'> 2010.07.12 13:03:35.400 frameworkd.subsystem DEBUG...in subsystem > ogpsd: found module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/__init__.pyo' > > 2010.07.12 13:03:35.406 frameworkd.subsystem DEBUGno plugin: factory > function not found in module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/__init__.pyo' > > 2010.07.12 13:03:35.419 frameworkd.subsystem DEBUG...in subsystem > ogpsd: found module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/nmea.pyo'> > 2010.07.12 13:03:35.426 frameworkd.subsystem DEBUGno plugin: factory > function not found in module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/nmea.pyo'> > 2010.07.12 13:03:35.434 frameworkd.subsystem DEBUG...in subsystem > ogpsd: found module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/ubx.pyo'> > 2010.07.12 13:03:35.440 frameworkd.subsystem DEBUGno plugin: factory > function not found in module '/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/ubx.pyo'> > 2010.07.12 13:03:35.455 frameworkd.subsystem DEBUG...in subsystem > ogpsd: found modu
Re: GPS stopped working, can't figure it out... what else?
On Monday 12 July 2010, Yaroslav Halchenko wrote: > On Sat, 10 Jul 2010, Al Johnson wrote: > > > * originally GPS worked for me without AGPS at all, just TTFF was > > > around > > > > > > 2 min > > > > It still should work. TTFF will be ~40s in ideal conditions, longer as > > that is exactly my problem -- it doesn't work at all -- most of the time > even GPS time is not acquired after tens of minutes being waited. > > just in case -- got account on online assist for ublox, used python > script from online with my account info and lat/long -- no change. > > is there any more lower level way to troubleshoot GPS (sending/receiving > expected input etc) than just eye balling stream of outputs from > gso-gpsd? fso-gpsd is a level removed from the gps, so isn't much use for debugging. You need to look at the debug output from ogpsd, or disable ogpsd entirely and look at the serial port directly. I think that's still configured through /etc/frameworkd.conf but it's a while since I've updated. http://wiki.openmoko.org/wiki/OpenmokoFramework#How_to_debug ogpsd uses the native ubx method to talk to the gps. There have been times in the past where duff init data caused the gps to crash, reset and start talking NMEA again. In that case you would never see a lock even if the gps had one because the ubx parser rejects the NMEA as invalid data. If you enable logging you will be able to see all this in the log. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: GPS stopped working, can't figure it out... what else?
On Saturday 10 July 2010, Yaroslav Halchenko wrote: > thanks everyone -- I will check it out although I am a bit confused > since > * originally GPS worked for me without AGPS at all, just TTFF was around > 2 min It still should work. TTFF will be ~40s in ideal conditions, longer as > * I thought AGPS feeding chip with previous locations was already > implemented and that is why there is a button to remove AGPS data > if you rellocate (used it few times, and then again acquired time/fix > within few minutes) It is, but I think there are deficiencies in the implementation. It seems to save incorrect data in some situations (like shutting down gps before it has a fix), then load it next time the GPS is started. Depending on how lucky you are it can then take a long time to get a fix, or not get one at all. In this case shut down the gps, remove the stored data, then start the gps again. > now I am experiencing now fixation (or even time acquisition) at all, > which sounds somewhat different... but ok -- I guess I better check > first what effect I would get with "online assistance". > > On Sat, 10 Jul 2010, Ian Darwin wrote: > > > I got me a password from u-blox.com and use the script from this page: > > > http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#GTA02_GPS_Hardware_Ass > > > ist_Feature (the python one). I set the values for lat and lon to known > > > values (for me lat=52.375756;lon=13.651114;) and feed the output into > > > /dev/ttySAC1 - this speeds up finding satellites alot. > > > > This is an important action if you're using the GPS. The wiki discussion > > cited above could use > > some cleanup but the information you need is there. Anyone using a FR > > device and wanting > > to use the GPS should be using this. There's even a version for Android > > On OM at > > http://androidgps.blogspot.com/2009/02/priming-openmoko-u-blox-gps-chip.h > > tml ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: usb jack already worn out?
On Wednesday 05 May 2010, Joachim Ott wrote: > Could it be that the usb jack is already worn out after 1,5 years? > I've made a short video: > > http://www.1qaz.de/usb_worn_out.mov (4,5 MB) > > I can move the plug a bit to the right and the LED goes off, there's > also a notice in the logfile: > > 2010.05.05 15:44:30.845 oeventsd.fso_triggers INFO Receive > PowerStatus, status = charging > 2010.05.05 15:44:44.27 oeventsd.fso_triggers INFO Receive > PowerStatus, status = discharging > 2010.05.05 15:44:44.42 oeventsd INFO turn led > gta02_power_orange off > > It's not the plug because it also happens with the usb cable or the > 2nd wall charger. The movement is similar on both my A5s. One is relatively deskbound so sees few insertion cycles, while the other is an everyday phone so sees quite a lot. The symptoms certainly sound like a problem with the socket though. > The date code of the device is 20080925. Can I do something by myself > to fix this? I guess if your soldering was up to the task you wouldn't be asking :-( ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Freerunner - I can recive sms but I can't send them...Why?
On Monday 19 April 2010, Adrian Carrera wrote: > Hi, > > I have a little problem here, and I don't know what's going on. I have the > Freerunner A5. This is what happened: > > I had SHR Testing Dic 10 2009 release on the phone and in the SD, but I > extensively used the system on the SD card. One day suddenly I was unable > to delete the sms messages, on theory the sms was deleted, but when I > restarted the system all the messages that I deleted were there again. > > This week I got the system message 'Delete some message data or you will be > unable to receive new message anymore' or something like this, so I > decided to changing, at least for that moment to the same system flashed > on the phone, but despite that this system had only 5 messages stored, the > same message about deleting message data to be able to receive new sms pop > up again. Weird 'cause this system is separated from the other in the SD > card. Then I decided to flash the phone with the last SHR Testing release > but the same issue, I can receive sms messages but I can send them. > > After updated the gsm to Moko11 and changing to last Android cupcake disto > to test, the same issue persist. > > What can I do? > > Any advice? Check for full message storage on the SIM, and delete some or all if it's full. You can probably do this in SHR from Settings -> Phone at the bottom of the page. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Problems with broken distro and AUX
On Wednesday 23 December 2009, Maciej Piechotka wrote: > On Wed, 2009-12-09 at 14:44 +0800, William Kenworthy wrote: > > Can you dismantle the case enough to access the switch body and press it > > possibly with a screwdriver top? It may only be the platic button thats > > broken, not the switch. > > > > BillK > > Does it have to be any guitar pick (I haven't recive any): > http://wiki.openmoko.org/wiki/Disassembling_Neo1973 It can be anything that is stiff enough but won't damage the case plastic. I usually use my finger nails or an old club membership card that's similar to a credit card but slightly thinner. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sooo... I may have blown up my battery.
On Sunday 20 December 2009, François-Léonard Gilbert wrote: > Using the charger to boot worked, thanks a lot! > > Now after 1 day of charging, the battery state is still zero bars. > The battery icon is still in the "charging" state, but if I unplug the > charger I get 0 bars and the "very low" battery alarm. Doesn't sound good > I tried reverting to the "dumb" battery meter, and the charge_now = > 136000 with charge_full=85 > > Is my battery toast? how do I interpret those numbers ( or those from > the bq driver)? The numbers are uAh, but since you are using the dumb battery driver they won't accurately reflect your battery's real capacity. What do you get with the usual driver? current_now and voltage_now might be helpful, both charging and unplugged. http://wiki.openmoko.org/wiki/GTA02_sysfs#.2Fsys.2Fdevices.2Fplatform.2Fbq27000- battery.0.2Fpower_supply.2Fbat.2Fcurrent_now http://wiki.openmoko.org/wiki/Battery_Questions_and_Answers#Why_does_.2Fsys.2Fclass.2Fpower_supply.2Fbattery.2Fcharge_full_says_i_have_a_850_mAh_battery_no_matter_what_i_use.3F ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sooo... I may have blown up my battery.
On Friday 18 December 2009, François-Léonard Gilbert wrote: > I hacked up an "adapter" (aka 2 wires) for a 3,7V cell phone battery > and booted my FR! That's my usual method (early gta02a5) > Unfortunately, after booting QtMoko, I removed the "jump-start" batt > and... the phone went dead. The "charging" battery icon was > visible, so I was getting some juice from USB. > > Any further tips? I can't plug the real battery in my FR to charge > it :-( Use the charger not USB. The charger gives 1A instead of the 0.5A from USB. If it still has trouble, disable the GSM and/or dim the display. GSM occasionally demands high current so you may just have been unlucky when you were swapping the battery. The display backlight at full brightness uses as much current as the rest of the phone put together, so dimming it can save a lot of current. > Is there a distro I could put on my SD Card that sucks less amps? Any > other tricks? Other than using the charger I've never needed any tricks. I've probably used every distro but the debian-based ones. > Thanks! > François > ___ > support mailing list > support@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/support > ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Xrander (Resolution question)
On Tuesday 08 December 2009, Iurii wrote: > Al Johnson wrote: > > As far as I know there is no way to use resolutions other than the ones > > xrandr > > already provides. 240x480 is an unusual resolution. If you explain why > > you need it we may be able to suggest alternatives. > > im really sory for the late answer the reason why i need that is that i > want to rewrite one of my applications to work on the FR but all the images > are sized for 240x480 > and im not an designer actually its little complicated to me to make a new > design for my program( > any syggestions? Depending on the app type it may be reasonable to put everything in a container fixed at 240x480. With a top bar above and a keyboard below this isn't far off normal size. You could try scaling the images for 320x640 and running in landscape. This isn't far off normal size with top bar. It should be quick and easy to scale a screenshot to find out how it would look. If the app is FOSS you might find a volunteer on the list to help with the artwork. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: GTK and FR
On Tuesday 08 December 2009, Iurii wrote: > i'm going on with my development from the time i received My FR > basicly the first thing ive done i have tried to write the "Hello word" > with GTK it looks fine > > secondly i have tried to write on the FR my application written before. > i dont like to deal with changing the kernel i prefer the stable one from > the factory > so my application is based on gtk+ > to actually run it on my old device i was using an image which is called > gumstix-x11-32mb-image and constists from next Recipe: > > IMAGE_INSTALL += " \ [snip list of packages] > now when im trying to run my soft on the FR which is runnig with GTA-02 rev > 20081029 > i get the illegal instruction error > i assume i need to add the packages wich i was using in my old image > gdk-pixbuf-loader-png \ > gdk-pixbuf-loader-xpm \ > gdk-pixbuf-loader-jpeg \ > > i have them in the .ipk for armv5te can i install them? if yes how ? Yes and no. You can install .ipk packages (see below) but armv5te is the wrong instruction set. This is probably the reason for the illegal instruction error. You will need to recompile for armv4t to run it on the Freerunner. > when i do > ipkg install > it says me that there is no sush a command as ipkg opkg install packagename ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Xrander (Resolution question)
On Thursday 03 December 2009, Iurii wrote: > Al Johnson wrote: > > I was trying to explain that it is not possible. > > sory i misunderstand :(so basicly there is no other way to change the > resolution?( which i need) > As far as I know there is no way to use resolutions other than the ones xrandr already provides. 240x480 is an unusual resolution. If you explain why you need it we may be able to suggest alternatives. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Xrander (Resolution question)
On Thursday 03 December 2009, Iurii wrote: > Al Johnson wrote: > > I think those are the only modes the LCD is capable of. You can't just > > add arbitrary modelines as you used to with analogue CRTs. > > good to listen that can you explain me how to do that please, if possible I was trying to explain that it is not possible. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sooo... I may have blown up my battery.
The only reliable method on my A5 is to jump-start the phone with another LiIon battery. Connect up the spare battery and boot, connect the external power then swap the battery for the dead one. After a few seconds the charging indicator should show flat but charging, and apm or the sysfs entries should show more detailed charging status. A spare openmoko or nokia battery is easiest, but i've used the one from my mp3 player and a couple of trailing leads when both my openmoko batteries were dead. just be very careful with the trailing leads! On Thursday 03 December 2009, François-Léonard Gilbert wrote: > You bet! Last time I let my battery completely discharge, I had to > do some voodoo to get it to running state, but nothing out of the wiki > article. > > This time, on the other hand, my FR shuts down even in the NOR boot > menu between AUX presses. I am ordering a battery tonight so I can > call around again. > > Unfortunately, I don't have a multimeter around, so I can't even know > the real state of the battery or the charger-supplied voltage. My > best option now is getting a known good one and hoping the phone starts. > > This brings me back to my original question: do any diagnostic > procedures already exist? I have an A6(date code 20081104) so it does > not work without a battery. > > Thanks for the support > > François > > Le 09-12-01 à 10:28, Tilman Baumann a écrit : > > That can only happen if the charger supplies more then 5V. > > Which is unlikely even for the cheap ones. > > > > I suppose you follow the guidelines on the wiki to get the phone > > back from > > deep uncharge. > > Freerunner can be difficult to get back to life once the battery is > > completely empty. > > ___ > support mailing list > support@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/support > ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Xrander (Resolution question)
On Wednesday 02 December 2009, Iurii wrote: > Hello dear all > > on my FR with GTA02 revision 20081029 > > i have a small problem > > when i"ve tried to change the resolution > xrandr -s 240x480 > i get the output: > Size 240x480 notfound in available modes > > can i somehow add the available modes? cause for my purposes i need > resolution to be 240x480 > > and the available modes are only > #xrandr > 480x640 > 640x480 > 240x320 > 320x240 I think those are the only modes the LCD is capable of. You can't just add arbitrary modelines as you used to with analogue CRTs. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Neo FreeRunner
On Wednesday 04 November 2009, Iurii wrote: > Michael Zanetti wrote: > > On Wednesday 04 November 2009 10:05:53 Iurii wrote: > >> i have a simple question does Neo FreeRunner has support for 3G data > >> cards? > >> i was thinking to start developing with openmokko project but the most > >> important thing to me is the GPRS > >> i our contry we have only the 3G... > >> but im really interested in openmoko... > >> any suggestions and answers will be really apriciated > > > > The freerunner has GPRS, but not 3G. However there is the possibility to > > attach an external USB 3G dongle. You can find more information on > > http://wiki.openmoko.org/wiki/UMTS > > tnx a lot very usefull suggestion > i will keep going then with openmoko ideas Also consider the gizmoforyou FLOW which is generally more capable but more expensive, and almost as open. http://www.gizmoforyou.com/shop/index.php?main_page=index&cPath=3_50 ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: illume-Keyboard lowercase?
On Thursday 08 October 2009, Nils Bokermann wrote: > Hi! > > I'm trying to get my Neo running with shr. Whenever I'm trying to type > in my password (consisting of upper and lowercase letters) I can use the > "shift" key on the "Terminal" keyboard, but a lowercase letter is sent. > > How do I get uppercase letters? Shift key gives upper case for me in shr unstable for every use I've tried. What exactly are you trying to do? ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: GPS problem
On Thursday 08 October 2009, Gabor Laszlo wrote: > On Thu, Oct 8, 2009 at 12:40 PM, Al Johnson > > wrote: > > You can find out which resources it knows about using: > > > > mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage > > org.freesmartphone.Usage.ListResources > > oh goody, it only says > [] > does that mean it knows of no resources? Yes, which means there's something very wrong with your setup. It should show WiFi, Bluetooth, CPU, Display and so on as well as GPS. > > > Documentation for the resource handling calls is here: > > http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesm > >artphone.Usage.html;hb=HEAD > > > > If it doesn't have a gps resource you'll need to set the log level to > > DEBUG in /etc/frameworkd.conf and check the log to see if there's any > > indication of a problem. > > Could you elaborate on that? /etc/frameworkd.conf has a log_level entry near the start that sets the default log level for all components. Other entries in that section control whether the log goes to a file, or to syslog. It all seemed fairly self explanatory last time I looked at it as the options were described in comments in the config file. > Maybe I should reflash it with the latest SHR, it's been awful long > time just doing the updates, I'm sure something's borken by now. That's a good idea. It takes us to a known good starting point. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: GPS problem
On Thursday 08 October 2009, Gabor Laszlo wrote: > On Tue, Oct 6, 2009 at 2:05 PM, Al Johnson > > wrote: > > On Monday 05 October 2009, Gabor Laszlo wrote: > >> after update of shr-settings, the switch to set gps to Manual-> always > >> on is gone. Anyone know how to set it by hand? (or how to fix > >> shr-settings)? > > > > mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage > > org.freesmartphone.Usage.SetResourcePolicy GPS enabled > > > > possible states are enabled, disabled, auto > > Thanks, > > I tried it but I get several warnings about a deprecated call, > (pending_return in dbus_connection_send_with_reply_setup() without > pending_setup), You can ignore this. It comes from a low level library, and until the library is fixed there's nothing devs using python can do to stop it. > and at the end > /org/freesmartphone/Usage: SetResourcePolicy failed: > org.freesmartphone.Usage.ResourceUnknown That's more of a problem as it suggests frameworkd hasn't found the GPS. Or I got the case wrong doing it from memory, which is less of a problem ;-) You can find out which resources it knows about using: mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.ListResources Documentation for the resource handling calls is here: http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Usage.html;hb=HEAD If it doesn't have a gps resource you'll need to set the log level to DEBUG in /etc/frameworkd.conf and check the log to see if there's any indication of a problem. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: GPS problem
On Monday 05 October 2009, Gabor Laszlo wrote: > after update of shr-settings, the switch to set gps to Manual-> always > on is gone. Anyone know how to set it by hand? (or how to fix > shr-settings)? mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy GPS enabled possible states are enabled, disabled, auto ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: OpenMoko + Exchange
On Tuesday 29 September 2009, not12listen wrote: > bringing this back from the dead... > > i've been off the OM boards for a bit, but my interest in owning one has > not diminished in the slightest. > > my question still stands... is there a reasonable method by which to > connect an OM device to an exchange server? > > in all honesty, if there is, i'd run out and buy one tomorrow... :) > > again, i am VERY green when it comes to linux, but is there a way to > package the Exchange connection add-on of Evolution to either Claws, > Openmoko Mail or Qtmail? or, is that idea much like re-inventing the > wheel? What _exactly_ do you mean by 'connect to an exchange server'? I ask because for some people it means 'read my inbox' while others think it means 'look and feel exactly as Outlook does.' There's a world of difference between them, and probably solutions for several points in between. What capabilities are deal breakers if missing, and which ones don't you care about? ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: MP3 'capable' [was: Meida player.]
On Thursday 10 September 2009, rakshat hooja wrote: > On Tue, Sep 8, 2009 at 8:20 AM, Wolfgang Spraul wrote: > > Rakshat, > > > > > > Actually Mplayer plays the MP3 with the user installed plugin > > > > (libmad > > > > or > > > > > eqvalent). Intone is just the frontend for Mplayer so no patent probs > > > > with > > > > > it > > > > Yes but we have to be careful that MP3 doesn't 'sneak in' somewhere. > > The moment anybody is selling a FreeRunner 'capable' of playing MP3, the > > patent guys have a case. 'Capable' can be a series of steps, including > > installing some software, etc. > > However, the moment those steps involve a resource out of control of the > > seller of the FreeRunner (say a random Internet URL), they have no case. > > > > Now with the vast pool of free software, what can easily happen is that > > MP3, > > MP4 etc. 'sneaks into' the product. Then someone downstream forgets that > > it's > > there, or it's very hard to remove, and falls into the trap. > > Yes I did follow the Openmoko Mp3 patent issues a long while back. > > I just wanted to ask you if things are ok re MP3 patents in the following > scenario > > We sell a device with no 'working' MP3 capablities but a preinstalled Music > player. The music player can take plugins and its website visibly > recommends downloading a plugin that enables MP3. Is the seller ok in this > situation re MP3 patents? That will depend on your local patent laws and, perhaps more importantly, whether you can afford to prove you're right. You'll have to ask a local patent lawyer about that. I doubt anyone on this list is qualified to give you an answer, so don't rely on anything you see here. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: SHR headphones not detecting
On Friday 28 August 2009, arne anka wrote: > there are two possible explanations: > - you have to push in the headphone plug harder to actually connect -- > hearing only in one earphone usually is a sign for that No. He said the speaker on the phone is also on, so the alsa state is still using the speaker, not the headset. In this case sound only goes to one side of the headphones. > - you needt to plug in _after_ establishing the call. not sure, how a) shr > handles that and b) if fso did fix it -- but with debian i frequently > experienced that the state file was switched only after establishing a > communication, ie when calling or accepting with the headphones already > plugged in, the state would nevertheless siwtch to handset, i had to > unplug and replug the headphones to make the state switch correctly. That indicates a bug in the state handling, either by the phone app or in rules.yaml. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Partitioning SD card for Android
On Tuesday 21 July 2009, Jette Derriche wrote: > On tir, 2009-07-21 at 18:55 +0100, Al Johnson wrote: > > On Tuesday 21 July 2009, Jette Derriche wrote: > > > On tir, 2009-07-21 at 12:39 -0400, François-Léonard Gilbert wrote: > > > > If your SIM card does not require PIN entry, Android shoud work; > > > > that's the only problem I had with the Koolu beta7 distro... so I > > > > had to go for something else. > > > > > > Oh...There must be a way to remove the pin. > > > > If you're using something FSO-based see: > > http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesm > >artphone.GSM.SIM.html;hb=HEAD#SetAuthCodeRequired > > > > I think this is available through the settings gui in recent SHR. > > Is QT Extended FSO based?... I am currently running version 4.4.2 No, it isn't. It should have an option in its settings to turn off SIM authentication, but I couldn't tell you exactly where. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Partitioning SD card for Android
On Tuesday 21 July 2009, Jette Derriche wrote: > On tir, 2009-07-21 at 12:39 -0400, François-Léonard Gilbert wrote: > > If your SIM card does not require PIN entry, Android shoud work; > > that's the only problem I had with the Koolu beta7 distro... so I > > had to go for something else. > > Oh...There must be a way to remove the pin. If you're using something FSO-based see: http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.GSM.SIM.html;hb=HEAD#SetAuthCodeRequired I think this is available through the settings gui in recent SHR. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Newbie introduces, and has problems
On Wednesday 15 July 2009, François-Léonard Gilbert wrote: > On the subject of flashing, is there any detailed explanation of the > architecture of an image? Are kernels and rootfs images mix-and-match? I > have seen that some distros only have a rootfs, others have both. Is > there a way to take an image of the current state of my phone before > flashing so I can keep settings, data, etc. when flashing back? tar.gz is for extraction to a partition on SD, and includes a kernel in the rootfs. jffs2 is a filesystem image containing the rootfs, but without the kernel. It is for flashing into NAND. The kernel needs the rootfs to provide matching kernel modules. If you stick to the kernel that matches the rootfs then the correct modules will already be there. If you start using other kernels you need to extract the matching modules-.tar.gz into your rootfs. Note that after 2.6.26 some of the interfaces changed, so using 2.6.29 with an image built for 2.6.26 probably won't work well even if you do include the right modules. For backup see: http://wiki.openmoko.org/wiki/Backup ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: volume
On Friday 03 July 2009, Seth Rothenberg wrote: > Have there been any developments on volume? > (Note, my Razr V3 isn't as loud as I would like either :-) > > The volume worries me enough that I asked > google if there are any pocket amps(found one :-) > > http://www.headwize.com/projects/cmoy2_prj.htm Judging by the headphone amp link I assume you're talking about volume on the headset. There's no progress since the problem and solution has been known since before the FR was released, and have been in the wiki for some time. Increasing the size of coupling caps improves bass response while shorting the 33R resistors increases output level with low-z headphones. Nobody is offering the mods commercially as opening the can makes the process prohibitively expensive, and there's no SOP. http://wiki.openmoko.org/wiki/GTA02_bass_fix There's no shortage of portable amps, but you may be better off with one that includes a USB DAC. This is because of the 160Hz bass rolloff even with high-z loads like an amp. Here are a few of the many on the market. Portable amps: Boosteroo HeadRoom AirHead Firestone Audio Fireye Graham Slee Voyager Portable amps with USB DAC: HeadRoom BitHead iBasso d2 Firestone Audio Fireye II ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Freerunner won't boot: dies in uboot
On Tuesday 30 June 2009, Chris Wright wrote: > 2009/6/30 arne anka : > > simply usb is still sufficient, only it takes longer. > > plug in, let it alone for the night and boot up next day. > > It's been plugged in for about 100 hours at this point, and went for a > stretch of about 50 hours without me touching it. No change in > symptoms. > > USB is not providing sufficient power for the phone to boot. Maybe > it's not detecting the presence of USB power, or not negotiating for > 500mA current rather than the default 100mA, or something like that, > but if leaving it plugged in overnight solved the problem, I wouldn't > have posted in the first place; if USB power were sufficient for it to > boot, I wouldn't have posted. Leaving it plugged in doesn't work with mine either. I jump-start using the single cell LiIon battery from my mp3 player, and some skinny wire. CAUTION: If you do this wrong you could damage your phone, your batteries and your health. LiIon batteries can make nice fires if you upset them. If you need to read the explanation below you probably shouldn't be trying this. I insulate the moko battery's terminals with paper or tape, then use the battery to hold the wires against the phone's contacts and hook up to the mp3 battery carefully. The moko battery has the polarity printed next to the terminals. Now: * Boot the phone * Attach the charger * remove the batteries and wires, being careful not to short anything! * remove the insulation from the moko battery if you taped it on * Put the moko battery in the phone. The phone should now show the battery as flat but charging. Give it a couple of hours and it should be fully charged. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: gsm problem
On Thursday 25 June 2009, Patryk Benderz wrote: > Dnia 2009-06-24, śro o godzinie 21:50 -0700, abatrour pisze: > > Do you have navit installed by any chance? That can break the audio. > > Could you be more precise? Currently i am testing OM2009R5 an i have no > sound in any sound player (didn't test phone calls). Can this problem be > connected with navit installation also? Navit has speech-dispatcher as a dependency, and that can cause problems with the audio. I'm not certain of the details but I think it hogs the OSS device, and can cause audio to stop working entirely after suspend. You can uninstall it entirely, or use one of the workarounds: http://wiki.openmoko.org/wiki/Navit#Speech http://kerneltrap.org/mailarchive/openmoko-community/2009/1/17/4756024 ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Fwd: Sound from mplayer to GSM]
On Tuesday 16 June 2009, Sten Kvamme wrote: > tis 2009-06-16 klockan 12:44 +0100 skrev Al Johnson: > > On Monday 15 June 2009, Sten Kvamme wrote: > > > mån 2009-06-15 klockan 09:51 +0100 skrev Al Johnson: > > > > On Sunday 14 June 2009, Sten Kvamme wrote: > > > > > > Set alsa controls > > > > > > 74 and 75 to true (Mono Mixer Left and Right Playback Switches) > > > > > > and start > > > > > > mplayer. Note you'll need to do this while in the call, or modify > > > > > > the gsmhandset.state file. > > > > > > > > > > This didn't work. I modified gsmhandset.state but music did not > > > > > sound in remote nor local handset. > > > > > > > > I missed control 1 (PCM Volume) which will need to be >0 for you to > > > > hear anything. > > > > > > > > If you want to hear it in the local handset you'll have to make sure > > > > it's routed to the speaker or earpiece as well as to the GSM module. > > > > Set controls 81 and 85 to true for this (left mixer left playback > > > > switch, right mixer right playback switch) > > > > > > > > I might have missed something else too... > > > > > > Great, thankyou! Kudos to you! > > > > Does that mean it works? If it does then please update the wiki. > > Yes it works, wiki updated. Good to hear. Thanks for the wiki update. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Fwd: Sound from mplayer to GSM]
On Monday 15 June 2009, Sten Kvamme wrote: > mån 2009-06-15 klockan 09:51 +0100 skrev Al Johnson: > > On Sunday 14 June 2009, Sten Kvamme wrote: > > > > Set alsa controls > > > > 74 and 75 to true (Mono Mixer Left and Right Playback Switches) and > > > > start > > > > mplayer. Note you'll need to do this while in the call, or modify the > > > > gsmhandset.state file. > > > > > > This didn't work. I modified gsmhandset.state but music did not sound > > > in remote nor local handset. > > > > I missed control 1 (PCM Volume) which will need to be >0 for you to hear > > anything. > > > > If you want to hear it in the local handset you'll have to make sure it's > > routed to the speaker or earpiece as well as to the GSM module. Set > > controls 81 and 85 to true for this (left mixer left playback switch, > > right mixer right playback switch) > > > > I might have missed something else too... > > Great, thankyou! Kudos to you! Does that mean it works? If it does then please update the wiki. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Dead Touchscreen, display is fine
On Monday 15 June 2009, vancel35 wrote: > I was out riding my bicycle this past weekend, and I don't have a carrier > for my FR to keep it easy access for splitting GPS tracks, so I carry it > against my skin. ziploc bags are great for cheap waterproofing when cycling. > I sweated on it, but it still worked fine. When I got home, I connected it > to my computer and transferred all of the TangoGPS files to my computer for > processing. I left my FR connected to my computer to charge it up. > > After a little time, I wanted to do something on my FR, but the touchscreen > was completely unresponsive. I tried taking the back cover off and the > battery out to let it dry for a few hours, but the touchscreen is still > completely dead, but as I said, the display works as usual. IIRC someone else had this problem after it got rained on. I don't remember if there was a solution. I would look for some debug output from the touchscreen driver to see if it's seeing something odd. > Another odd issue is that it normally charges in a few hours connected to > my computer, but after leaving it connected all night last night, it's > still only at about 80% charge. That sounds like the normal, correct operation of the PMU to stop it killing the battery. See: https://docs.openmoko.org/trac/ticket/1158#comment:63 > Is there a connector that may have gotten wet, or anything that may just > require me to take the cover off and have a look? > > Thanks for any info, > > Laura ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Om2009] Python application development
On Monday 15 June 2009, David Fokkema wrote: > Hi list, > > I've been browsing the wiki, but not really 'getting' it, I suppose. > Apart from running on my device, what are the options for application > development in python for Om2009? I'm really asking how to develop > applications on my laptop and to test paroli / illume integration and > such. I want to run it inside something like Xephyr, but I can't figure > out how to do that correctly. MokoMakefile says not to use MokoMakefile > for application development but to use a toolchain, but that's not > really necessary, right? Should I use MokoMakefile to build a qemu > emulator and then flash the latest Om2009 images? Or should I really > just run on the device? MokoMakefile is a convenience wrapper for setting up OpenEmbedded to build for Om2009, and to do the builds. There are similar makefiles for FSO and SHR. If you want to target these images in future then it's probably worth the effort to find out how this works as it makes packaging and possible inclusion in default images and/or feeds _much_ easier. You could just ignore it until you want to package though. For basic python development I usually edit on the laptop or desktop and run on the phone via an ssh session or two. If you replace dropbear with openssh you can use fish:// or the gnome equivalent to edit on the laptop while the files are on the phone. Display redirection works too, but often gives odd scaling because of the different dpi settings on each display. > (It's a shame that a lot of info on the wiki seems to be outdated) True. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Fwd: Sound from mplayer to GSM]
On Sunday 14 June 2009, Sten Kvamme wrote: > > Set alsa controls > > 74 and 75 to true (Mono Mixer Left and Right Playback Switches) and > > start > > mplayer. Note you'll need to do this while in the call, or modify the > > gsmhandset.state file. > > This didn't work. I modified gsmhandset.state but music did not sound in > remote nor local handset. I missed control 1 (PCM Volume) which will need to be >0 for you to hear anything. If you want to hear it in the local handset you'll have to make sure it's routed to the speaker or earpiece as well as to the GSM module. Set controls 81 and 85 to true for this (left mixer left playback switch, right mixer right playback switch) I might have missed something else too... ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sound from mplayer to GSM
On Tuesday 09 June 2009, Sten Kvamme wrote: > Have someone played sound from mplayer to GSM? I don't know if it's been done, but it should be very easy. Set alsa controls 74 and 75 to true (Mono Mixer Left and Right Playback Switches) and start mplayer. Note you'll need to do this while in the call, or modify the gsmhandset.state file. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Om2009] PIN & PUK
On Monday 08 June 2009, David Fokkema wrote: > On Mon, 2009-06-08 at 12:15 +0300, Risto H. Kurppa wrote: > > On Mon, Jun 8, 2009 at 11:36 AM, David Fokkema wrote: > > > Hi list, > > > > > > Getting a bit too confident, I decided to change the PIN (default ) > > > of my SIM. > > > > > > 1. Paroli doesn't require you to re-enter the PIN, to make sure you > > > made no typo's. > > > > > > 2. Paroli doesn't give feedback on incorrect old PIN values, so you > > > don't really know for sure the PIN was actually changed. > > > > > > 3. On startup, unlocking the phone with your PIN is not very verbose. > > > An incorrect PIN results in another 'enter your PIN' screen, but > > > nothing like 'PIN incorrect, only 2 tries left'. > > > > > > 4. When the SIM is blocked (incorrect PIN) nothing shows in Paroli. It > > > doesn't tell you that the SIM is blocked and that you now need to enter > > > your PUK code. Having already tried a few times, I asked a colleague > > > for his unlocked phone to really make sure I wouldn't block the SIM by > > > entering incorrect PUK codes. > > > > > > So, does anyone dare reproducing this, ;-) ? > > > > Thank you David for sharing your experience! I don't think we'll soon > > find anyone ready to test this (maybe with old SIM cards..). Could you > > please report all this to http://www.paroli-project.org/trac so it > > will not get lost in the mail archives. I think this is something > > quite important to be fixed.. > > I might try a few times. Apparently, as long as you're not entering an > incorrect PUK code ten times, all is well. Of course, an unlocked phone > nearby is necessary to the whole procedure. Why? You can just use mdbus to enter the PUK and set the PIN: http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.GSM.SIM.html;hb=HEAD#Unlock ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: help for newbie, and some python
On Wednesday 03 June 2009, Ovidiu Gavril wrote: > Ok, but if I install OM2009, is it a sure way to solve my problems? > I'm more interested in Dbus problem than the opkg update problem. Om2009 is using paroli and frameworkd, both of which are written in python, and communicate using dbus, so you shouldn't have any problems with it. I don't know anything about the org.openmoko.Dialer dbus interface you are using, but I guess it is now replaced by frameworkd. I don't think I ever tried Om2008.12, but afaik it didn't make much use of dbus or python. I guess you would have had to install extra packages to get them working, but it looks like you are missing a python package, and the dbus session bus isn't started despite your use of dbus-launch. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Om2009 testing release 4
On Wednesday 03 June 2009, Kevin Day wrote: > On Tue, Jun 2, 2009 at 9:50 AM, Al Johnson > > wrote: > > On Tuesday 02 June 2009, Robin Paulson wrote: > >> 2009/6/2 Al Johnson : > >> > On Tuesday 26 May 2009, Robin Paulson wrote: > >> >> there's no incentive i can see to stay with uboot > >> > > >> > You probably don't have 4 different distros on your SD then ;-) > >> > >> no, i don't. > >> > >> but it doesn't look like it will be long before qi can do multi-boot > >> > >> http://wiki.openmoko.org/wiki/Qi#Boot_Menu > > > > It's been done already - there was a thread about building the minimal > > kernel and rootfs, and using it to kexec into the one you really want to > > boot. Unfortunately that takes up another partition that I just don't > > have spare due to the kernel limitation on partitions in mmcblk devices, > > and android's thirst for partitions. This could be worked around too, but > > as I already have a working uboot setup there doesn't seem much point. > > I've nothing against Qi, but in my case uboot is the better tool for the > > job. > > What one could do is create an initramfs and build it directly into the > kernel. The small rootfs would exist with the boot kernel on any desired > partition (say partition 0), taking up no more partitions than already > used. That's one of several possible workarounds, but it's not very helpful given that the partitions tend to get reformatted and have a new tarball extracted over them fairly often. The workarounds all involve extra work for little gain. One thing that would fix it would be if Qi would check the last partition, which may be a partition that is outside the kernel partition limit. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: help for newbie, and some python
On Wednesday 03 June 2009, Anthony Winter wrote: > On Wed, 03 Jun 2009, Robin Paulson wrote: > > 2009/6/3 Anthony Winter : > > > OK, good start. But - assuming that it does run from a command line > > > (and I still haven't found a terminal yet, but there must be one > > > somewhere), what are the steps in getting it run by 'clicking' on an > > > icon, in > > paroli/illume? > > > > That's the missing bit... > > > > i assumed you were connected via ssh, and could get at a terminal that > > way > > er no, I want to write apps that will be used on the phone. In the field. > In a hurry, sometimes. Create a .desktop file in /usr/share/applications, in this case probably called /usr/share/applications/base.desktop. The easiest way to do this is probably to copy and modify one of the other files in that directory, but the format itself is standard: http://standards.freedesktop.org/desktop-entry-spec/latest/ For the icon to appear in the illume launcher the Categories entry has to include Applications. > > i can't remember if there is a terminal in om2009 or not - i think > > there is, and it's pretty good. have you discovered illume ie the > > desktop yet? if not, you might want to go to > > http://wiki.openmoko.org/wiki/Paroli#FAQ > > specifically, "how do i get illume?" > > I have discovered it, and while the initial frustration level has receded, > I still haven't got the hang of it yet. I'm beginning to see why Apple have > captured the non-geek market. > > > where all your questions will be answered > > Not really. For example, the OM2009 link is to Elementary, which looks > neat, but a) it's not gtk, and b) it's in C, and life (and in particular, > the possible life of a Neo) is too short to write apps in C. So I need > something with python bindings. Elementary also has python bindings, but if you prefer to stick to gtk you can. You may need to install gtk and its python bindings if they aren't in Om2009 by default. Installing the bindings should pull in the required gtk packages: opkg install python-pygtk Depending on what you're doing you may need other packages as opkg is more granular than most package managers. You can check what's available with something like: opkg list |grep gtk opkg list |grep python > > the wiki is great, have search - there's mountains of useful info there > > Weel, there is a lot there, but I haven't yet found the key to doing > what I want... ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Om2009 testing release 4
On Tuesday 02 June 2009, Robin Paulson wrote: > 2009/6/2 Al Johnson : > > On Tuesday 26 May 2009, Robin Paulson wrote: > >> there's no incentive i can see to stay with uboot > > > > You probably don't have 4 different distros on your SD then ;-) > > no, i don't. > > but it doesn't look like it will be long before qi can do multi-boot > > http://wiki.openmoko.org/wiki/Qi#Boot_Menu It's been done already - there was a thread about building the minimal kernel and rootfs, and using it to kexec into the one you really want to boot. Unfortunately that takes up another partition that I just don't have spare due to the kernel limitation on partitions in mmcblk devices, and android's thirst for partitions. This could be worked around too, but as I already have a working uboot setup there doesn't seem much point. I've nothing against Qi, but in my case uboot is the better tool for the job. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Om2009 testing release 4
On Tuesday 26 May 2009, Robin Paulson wrote: > there's no incentive i can see to stay with uboot You probably don't have 4 different distros on you SD then ;-) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [HW] Ear phones with microphone, for hands-free calling?
Apart from the inline bits below, note that the mic on the headset will probably suffer from buzz heard at the far end. Bluetooth is probably a better bet as it won't suffer from buzz. On Saturday 28 March 2009, Toni Mueller wrote: > Hi, > > On Sat, 28.03.2009 at 16:20:11 +0100, arne anka wrote: > > I wrote: > > > external in-ear head set that also features a microphone be a good > > > thing to have for this device. > > > > afaik the package included a wired headset too. > > mine didn't, and afaik, the offered headset does not include a > microphone. For a while there were some free extras while stocks remained, and a headset with mic was part of that. This might have been limited to 10-packs > > resellers of the fr do imo offer the matching headset. > > ... w/o a microphone. I have seen resellers offering the headset mentioned above separately in the past, but they may now be out of stock. > > for other see either the archives or the wiki. there have been lengthy > > I was already looking out there, but didn't turn up anything useful > there. Google's top hit for 'openmoko headset pinout' will give you this: http://wiki.openmoko.org/wiki/Headset > > sure, but i am not sure, if handsfree equals headset. at least headphones > > are forbidden (even for bicycles, but nobody cares). > > If it would be possible to connect the phone to a car radio - some of > these include an USB connector, that would imho solve the problem and > provide muting as well as the option to use the car's stereo for voice > output. But I don't know how this can be made to work. Bluetooth hands-free kits are cheap and should work. Some cars have these as part of the stereo. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [HW] microSD card mount needs redesign
On Wednesday 25 March 2009, xChris wrote: > 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... If that's the reasoning then we shouldn't be able to hotplug USB either, as rootfs could be on a flash drive or NFS. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [HW] microSD card mount needs redesign
On Tuesday 24 March 2009, Alexander Shulgin wrote: > I've brought a card reader to use with my FR's microSD card (via > supplied adapter); and I have to say that I've had a very hard time > getting the card out of the device. > > The card mount just _needs_ redesign. With current version one have > to apply too much force at the sensitive parts of the device to get > the damn card out of it! Try Joerg's sticky tape mod - it's quick, easy, cheap, and if you don't like it it's easily reversed. http://people.openmoko.org/joerg/sdcard-handle/ ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: FR: Problems, problems: please help
On Monday 23 March 2009, Toni Mueller wrote:
> Hi,
>
> about one or two weeks ago, I've purchased a new FR, but haven't gotten
> it to work as much as to be usable as a phone yet. The only application
> that seems to be reliable so far is "sudoku", which I don't need.
Few people can agree on what a 'usable phone' is, but some of us have found
combinations that make the Freerunner usable for us. There are a _lot_ of
options though, so some perseverance may be needed in finding the right
combination. I hope you find something that works for you.
> The gory details:
>
>
> When the phone came, it appeared to be flashed with Om2008.8, from the
> looks of the screen (black background).
>
> Today, I tried to re-flash the device with Om2008.12 using dfu-util,
> and got messages like
Snip reasonable looking dfu-util output
> While flashing, the FR displayed appropriate message like "writing root
> file system" (or so).
>
>
> I didn't flash the u-boot, since it was said that that wasn't needed,
> except in very rare cases. The wiki is a bit unclear about that,
> however.
There were a few issues with uboot early on, but if yours shipped with 2008.8
it probably has a fixed version. There may be an argument for updating to Qi,
but you are probably better off sticking with uboot for the moment.
> After a reboot, nothing seemed to have changed. I still have a black
> background (I don't mind that, however).
>
>
> The next step was to set up the USB networking. After doing so, I
> collected some info from the system:
> Hardware: GTA02
> Revision: 0360
> Serial :
>
> (The device was "advertised" as being a GTA02v6, whatever that may mean.)
GTA02 is the Freerunner. v6 is the board revision, and the 0360 shows that it
is v6 that you have. It includes a couple of relatively minor improvements
over v5, and is AFAIK still the latest version shipping.
> In any case, I thought I'd try with 'opkg', eg. 'opkg update', and
> 'opkg upgrade'. I found no way to download upgrades for the system,
> and no way to upgrade to Om2008.12 this way.
This may be because of a networking problem, or the repositories may have
moved. The URLs for the repositories can be found in files under /etc/opkg. I
can't comment on the specifics for 2008.12 as I haven't used it.
> What's (not) working now:
>
> * I can press buttons. Sometimes, the associated application starts
>("Settings": rarely, "Locations": 2/3 of the time).
>
> * Handling is generally clumsy - the phone is _slow_.
>
> * I can make and receive calls. I sound like I'm in an old oil can,
>however.
More recent distros (should) have fixed the echo problem.
>I get no ring tone, and generally have a very low audio volume.
Low audio volume can be fixed by adjusting the mixer settings. I find manually
adjusting the config files easiest, but there is also a GUI available. See:
http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem
>Using the phone near a server (no problem for my old standard phone,
>a 6230i) can safely be ruled out that way. It also only works when
>I'm standing near a GSM station. At home, where my standard phone
>gives me _all_ bars for GSM field strength, I get "no service"
>instead of the field strength indicator (I'm using T-Mobile/D1,
>in Germany). When I was able to inspect the settings, it said "Ring
>and vibration".
This seems odd. My FR has similar sensitivity to my old k700. It might be
worth checking the label under the battery to see you have the
900/1800/1900MHz European version not the 850/1800/1900MHz US version.
> * GPS does not work. So far, I _never_ got a GPS position, even not
>with an external GPS antenna. The one time I was able to fire up
>"Settings", and on every attempt to use "Locations", I said "yes"
>to enabling GPS, to no avail.
I assume that's a 2008.12 bug.
> * Software upgrade(s) may or may not have succeeded - I can't really
>tell at this point because proper documentation does not appear to
>be available. At least, the image shown for 2008.12 is not what I
>see on my phone, and no version number matches exactly what I have.
>
>
> FWIW, I expect to be able to use the device as a phone, a navigation
> system, a music player and voice recorder.
That should be possible. tangogps and navit provide mapping with raster and
vector maps respectively. There are several music player apps, and 3 or so
voice recorder apps in active development. Most of these will appear in the
list at opkg.org though there have been some problems with packages downloaded
from there recently.
> After investing some 20 hours or so, I'm now at a loss and don't know
> what else to try.
Try some of the other distros. You may find it easier to boot off SD rather
than reflash every time, and you could even dual- or multi-boot. See:
http://wiki.openmoko.org/wiki/Booting_from_SD
See http://wiki.openmoko.org/wiki/D
Re: Wifi issues in SHR-Testing
On Sunday 15 March 2009, William Kenworthy wrote: > On Sun, 2009-03-15 at 19:38 +0100, Johny Tenfinger wrote: > > If you want to connect with open network, you don't have to add it > > manually to that file. In future shr-settings will have WiFi manager > > based on FSO dbus calls. > > Hopefully it will use wpa-supplicant and not go off and do something > weird and non-standard like the rest of the FR. It looks like it'll be using wpa-supplicant and connman ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO/SHR-testing] Too much echo suppression?
On Thursday 12 March 2009, Vasco Névoa wrote: > Hi all. > > I've been happily using SHR without any GSM call echo, but the callers > do complain that they hear me badly. > I've tried calling the Neo from a landline, and I think the Neo is > chopping the sound, making it hard to understand. I don't think it is > a problem of volume. > I think this is probably the result of echo suppression/cancellation > being set too strong... > I'd like to experiment with various levels of echo processing; where > do I find info about the available AT commands, and where in FSO do I > have to tweak? The AT commands appeared in this mail to the hardware list: http://lists.openmoko.org/pipermail/hardware/2008-August/000451.html The descriptions are the string returned by the modem when the command is entered, and that's as much as we know. The numbers appear to make a bitmask, but the modem will only accept the numbers listed. Look in /usr/lib/python2.x/site- packages/framework/subsystems/ogsmd/modems/ti_calypso/channel.py where x will depend on whether your image is using python 2.5 or 2.6. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Help! GSM not working after updating to Moko10
On Friday 27 February 2009, Ingvaldur Sigurjonsson wrote: > 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 ? What precisely do you mean by 'completely bricked'? You shouldn't be able to brick Freerunner without a debug board. The NOR uboot should always be available by pressing and holding Aux then pressing and holding Power when switching on. It has a short timeout so you will need to type quickly, or have the dfu-util command ready to run. Problems reported so far have all had a solution: * Having other dfu-capable usb devices plugged in may cause problems. Either unplug them or specify the usb id of the Freerunner in the dfu-util command. * remember to run dfu-util as root. * Using dfu-util as provided by their linux distro (ubuntu/fedora/whatever) may not work. Using the version supplied by openmoko works. * It may be unusually sensitive to dodgy USB cables. Changing cable may help. * Some people have to start uboot before connecting the USB cable. * It may work in some USB ports but not others. Try a different port. If you can't get to the NOR uboot then check your battery isn't flat. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Using FSO
On Monday 23 February 2009, Lucas Lacroix wrote: > Can anyone send me a link on how to get FSO working correctly? I got > milestone 5, which seems stable, but there is no phone app and I can't find > anything to install via the repositories. FSO has 3 levels of image: openmoko-fso-console-image - framework with console but no GUI openmoko-fso-illume-image - framework and minimal X plus illume openmoko-fso-image - framework, X, illume and apps It sounds like you picked up the illume image rather than the full one. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Audio Buzz / Rattling Issue
Before going any further I suggest you read this:
http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem
It tells you where the alsa state files are kept, what state files there are,
what they do, and which alsamixer control does what. It links to a page that
gives more detail of the underlying audio hardware, and to a volume control
GUI.
2008.x does not change the mixer state on headset jack insertion or removal,
but the kernel does create an input event that would allow it to do so. FSO
should switch from speaker to headset, but this isn't extensively tested and
may be buggy.
The 'buzz' that most reports refer to is heard during phone calls by the
person on the far end of the call, not on the FR itself. The buzz you hear
seems like either a distortion from the media player or a mechanical issue in
the speaker of your unit.
On Sunday 08 February 2009, Kevin Day wrote:
> > I have never tested the headset, I did now and I have the same behavior
> > you are describing !!
> > The sound never goes to the headset it keeps on the FR.
> >
> > Does anyone else have this problem? I am using 2008.12 also.
> I would like to update with information I gained from further testing.
>
> I was able to get something close to normal audio output and even enable
> the external speakers.
> (however, the actual problem is still not _fixed_ at this time)
>
> I do not remember the exact order things were done in, so here are the
> rough steps:
> WARNING: these are done from a console, so you need to learn/know how to
> get console access first.
>
> first, I went to trac bug #1640, downloaded, and extracted this file:
> http://docs.openmoko.org/trac/attachment/ticket/1640/scenarios.tgz
>
> I then backed up my original asound.state file:
> # cp /etc/asound.state{,.orig}
>
> Of the extracted files (from scenarios.tgz), I took the stereoout.state
> file and replaced my existing asound.state file:
> # cp stereoout.state /etc/asound.state
>
> I then ran the alsactl tool to restore the sound settings from the brand
> new asound.state file:
> # alsactl restore
>
> The next thing to do was to play around with the alsamixer setting so
> see what does what..a royal pain in the ?undocumented? butt.
> # alsamixer
>
> Here are the important settings:
> PCM - thats your main audio
> Amp Spk - this seems to cause problems, when enabled it causes all
> stereo audio (right and left) to output only to one speaker. Disable
> this and suddenly you can get right+left through separate speakers.
> Amp Stat - not sure what this is for, but turning it off turns off all
> audio.
> DAPM Stereo Out - This seems to be your onboard speaker, turn it off to
> turn off your onboard speaker
> DAPM Handset Spk - This is your external headset; turn it on to turn on
> the external speakers!
>
> I set the above to the following:
> PCM - anything above ~60% produces audio; this does not seem to cause
> the buzz/rattle
> Amp Spk - OFF!!
> Amp Stat - On
> DAPM Stereo Out - off
> DAPM Handset Spk - On
>
> Now save your changes:
> # alsactl store
>
> The next step was to turn the music player's audio volume down to about
> 5-10%
> The volume bar is ~3 millimeters in length
> This is not the alsamixer volume, it is the media player's volume.
> The media players volume is quite difficult to get to, you will have to
> fight with the song seeking to get the volume to change.
> Not a very user-friendly design in my opinion..
>
> Once the music player is at 5-10% in volume, you will no longer have any
> easily noticeable buzzing or rattling.
> Of course, you won't be able to do any volume changes when not plugged
> into a computer.
> In addition, you will not be able to swap between internal and external
> speakers while not plugged into some desktop computer as well...
>
> The next problem is that, even though there seems to exist the boot
> script: /etc/init.d/alsa-state
> the sound settings are not restored when a reboot is made.
> So, every single time the device gets powered on, one will need console
> access to correct the audio settings with the command:
> # alsactl restore
>
> Unless one is willing to tug around an entire computer or notebook
> (laptop) in addition to the freerunner a person pretty much cannot
> change any of their audio settings.
> That is not good at all, particularly for a cell-phone.
>
>
> The problems at this time are as follows:
> - inability to manually mute/unmute the internal and external speakers
> via the freerunner user interface
> - inability to raise software controlled volume above ~10% without
> incurring audio buzz/rattling issues
> - inability to restore saved audio settings between boots...why?
>
>
>
> ___
> support mailing list
> support@lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/support
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO] Wifi in M5 no longer functioning
On Thursday 05 February 2009, Dylan Semler wrote: > On Wed, Feb 4, 2009 at 7:47 AM, Al Johnson wrote: > > I often get the above even with a working wpa_supplicant.conf because the > > dhcp > > discover starts being sent immediately, not after association, so dhcp > > times > > out before association is complete. Bringing the interface down then > > immediately up again will often get association faster, so the last dhcp > > request succeeds. > > Do you mean, after SetResourcePolicy WiFi enabled, you can do ifdown eth0, > ifup eth0, and it works? Or do you cycle the SetResourcePolicy WiFi? > Neither seems to work for me. I've been looking at this on recent SHR which I think is largely similar to MS5, but it's possible there are differences in this area. 'SetResourcePolicy WiFi enabled' tells FSO to power up the WiFi irrespective of whether any apps have issued 'RequestResource WiFi'. Before I do this I have no eth0 available. To get dhcp working I would often have to do: ifup eth0 ifdown eth0 ifup eth0 On the second ifup the association often completes a little quicker so dhcp has a chance of completing before timeout. Another method is to manually start dhcp after the first ifup using something like: udhcpc -i eth0 This assumes wpa_supplicant is making the association fine. You can check that with wpa_cli which accepts a 'help' command to tell you what other options it has. This has worked for me on everything I've tried since 2007.2, but I've not tried it on the recent SHR or MS5 yet. SHR, and probably MS5, have the added complication of connman running. This tries to manage the network connections, but at least for usb0 it is overridden by the ifup and ifdown commands. Assuming connman actually works, the other option would be to use the connman dbus interface to set the network parameters. Don't ask me how though ;-) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO] Wifi in M5 no longer functioning
On Wednesday 04 February 2009, Dylan Semler wrote: > On Wed, Feb 4, 2009 at 1:40 AM, Michael 'Mickey' Lauer > > wrote: > > That's correct behaviour due to auto-release. Please read the usage > > introduction at http://docs.freesmartphone.org/usage-intro.html > > > > If you can't stay on the bus, use SetResourcePolicy. > > My bad, I hadn't read far enough before to catch the note about mdbus at > the bottom. I've set the policy to enabled, but still having troubles > > r...@om-gta02:~# mdbus -s org.freesmartphone.ousaged > /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy WiFi > enabled > r...@om-gta02:~# mdbus -s org.freesmartphone.ousaged > /org/freesmartphone/Usage org.freesmartphone.Usage.GetResourceState WiFi > True > r...@om-gta02:~# ifup eth0 > WPA: Configuring Interface > ioctl[SIOCSIWENCODEEXT]: Operation not supported > ioctl[SIOCSIWENCODEEXT]: Operation not supported > ioctl[SIOCSIWENCODEEXT]: Operation not supported > ioctl[SIOCSIWENCODEEXT]: Operation not supported > udhcpc (v1.13.2) started > run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1 > Sending discover... > Sending discover... > Sending discover... > No lease, failing > > I don't _think_ it's a configuration issue, as my setup hasn't changed > since M4 and I'm using the same config files. I often get the above even with a working wpa_supplicant.conf because the dhcp discover starts being sent immediately, not after association, so dhcp times out before association is complete. Bringing the interface down then immediately up again will often get association faster, so the last dhcp request succeeds. > Really all I'm wanting to do is enable wifi so I can opkg some packages > from the command line, etc. Am I going at this the wrong way? > > Dylan ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Distro?
On Wednesday 04 February 2009, Seth Rothenberg wrote: > Another follow-on question. > It appears that the phone I am using now > does not have the capacitor fix. > > I have 2 questions: > 1. is the software patch available for > various distros, eg, SHR? It's been in the kernel for a long while now. It is as effective as the hardware fix, possibly more so. With a favourable satellite constellation I get ~40s TTFF from cold, even with SD activity. Any recent distro should have it. With FSO/SHR you might see problems related to loading almanac, ephemeris and time when powering up the GPS. The docs suggest that even with incorrect or outdated data the TTFF should be no worse than an unaided start, but in practise it seems that it can cause significant delays. Some versions of ogpsd have had significant problems in this respect. Make sure your time and timezone are set correctly as this can slow things down too. > 2. Is the hardware fix documented > for DIY? I think so, but it is completely unnecessary with a recent kernel. > The phone I have that was able to get a fix... > it seems to have a microscopic solder joint > between the 3rd and 4th pins from the bottom > on the SD slot. (there could be a cap in there :-) > > The phone I am trying to work with... > does not have this solder work. > > ___ > support mailing list > support@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/support ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Distro?
On Sunday 01 February 2009, Seth Rothenberg wrote: > Dear friends, > I'll be travelling and thought I would bring along FR. > I'm considering which distro to bring. I have most of this working with FSO Milestone 4.1 plus packages from http://openmoko.truebox.co.uk/repos/mazikeen/fso-testing/ipk/ You can safely add this as a repository for FSO. Debian will probably do nicely as well, but I haven't tried it. > I hope to have > *phone - even if it's just to know when I > have to find a land line to call home. > I can't access the SIM until I get there. Make sure you update the gsm firmware to moko10 for widest SIM compatibility if you haven't done so already. > *notepad - just something to reduce lost paper I use a combination of the sketchbook app from FSO and abiword from the repos mentioned above. > *wifi - possible? I do this manually using the same manual wpa-supplicant configuration I originally used under 2007.2. It should still be in the wiki. > *vpnc - google seems to say, I need debian. I don't have a package for this. If nobody else has built it then debian may be your only answer. > That's OK with me if it has the phone apps. > > gps (I can dream, can't I?) Dream? That's probably the easy bit! Zhone can give you basic location. Tangogps works nicely with tiled maps, and navit does quite well with vector maps. Tango looks prettier, but the maps take up much more space. Just make sure you get a recent navit package from: http://download.navit-project.org/navit/openmoko/svn/ > I have FDOM back in October, and it worked. > Doesn't seem to work for me now. > (i.e., it crashes). > > Thanks for humoring me... > Seth ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: bad time_and_date from gpsd again
On Thursday 15 January 2009, Joachim Ott wrote: > 2009/1/14 Daniel Willmann > > > Since you talked about gpsd (I am assuming you're not using FSOs ogpsd > > and compatibility layers) the aiding stuff will not work and you will > > need to wait for the right time for some while after powering on the > > GPS. > > That's wrong. I'm using SHR, I have disabled the gps stuff from fso and I'm > using the gpsd from 2007.2. I use the aid-data from ublox and I get 12/5 > satellites (or more) within 60 seconds. "Won't work" in that it isn't included in gpsd while it is included in ogpsd, rather than it's impossible to do. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: bad time_and_date from gpsd again
On Wednesday 14 January 2009, Sten Kvamme wrote: > The following shows some strange behaviour from gpsd. The current time > is 19.18 and year 2008-01-14. Why is the time incorrect from gpsd? > > r...@om-gta01:~# telnet localhost 2947 > d > GPSD,D=1999-11-30T23:59:46.00Z Because that's the time that it cold starts with, and will keep reporting it until it gets the correct time from a satellite. If you feed it a time with an AID-INI message then it'll report that time until it gets the correct one from a satellite. The correct time is one of the first things it picks up, so it will appear even before it has a location fix. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO] Re: Call Volume on wired headset
On Wednesday 14 January 2009, Marcus Stong wrote: > Hey Al, > Phone's gta02 with FSO milestone 4.1. > I changed the values back up to 127 and 7, and rebooted, and then made a > call, with no difference. I wonder does FSO or zhone not use the .state > files? FSO is certainly aware of different state files, and provides methods for apps to switch them nicely. I haven't looked at headset detection in FSO though, so it may be it's not there yet, or that zhone isn't using it. > Just to be clear, I'm changing the gsmheadset.state file at > /usr/share/openmoko/scenarios That's correct. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
[FSO] Re: Call Volume on wired headset
On Wednesday 14 January 2009, Marcus Stong wrote: > I'm using the latest testing milestone of FSO Please quote the actual version number to avoid confusion. As I understand it 'latest milestone' is currently 4.1. It also helps to know whether you have gta01 or gta02 as the mixer channel numbers are apparently different. > , and am trying to get the > wired headset working better on zhone calls. The earbud volume is rather > weak. I've altered gsmheadset.state control.3 values to 1 (from 87). It's > turned up the volume a bit, but still not enough. That's odd - setting it to 1 should give almost no output, at least on a gta02. Mine is at 96 and maxmum is 127. > I also changed the value of control.6 to 1 as well. >From what? Mine is at 7 (maximum) > Maybe I'm not getting how this works. I tried the maximum value of > control.3 (120 or something), but that seemed to make it quieter. That's very strange. It seems as though you are editing the correct controls, and the differences should be obvious given the large level changes you seem to be making. I can't test it myself until I've resoldered my headset, but I've not had any problems with it in the past when changing audio settings. i haven't checked to see that FSO does actually use the gsmheadset.state when the headset is plugged in. I assume you are editing the file, saving the changes then starting a new phone call to test the settings. > Can someone guide me on how to make the wired headset louder. It's now a > law in Ontario that you have to use hands-free while driving, and right > now, I won't be able to hear anything with noise created driving on the > highway. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [2008.x] quasar on openmoko
On Tuesday 13 January 2009, Robin Paulson wrote: > i'd like to put quasar on my neo, and they offer downloads for various > arm architectures, but i'm not sure which is correct and i don't want > to risk fubaring something. can somebody advise which to use? > > http://katastrophos.net/andre/blog/software/quasar-media-player/#tdownloads > > of course, i assume the correct dependencies are in the repos... AFAIK all the distros for OM are using EABI and the cpu is armv4, so quasar_0.9b3_1_armel.deb looks the best bet from the binary point of view. For debian the packaging and deps would probably work too, but for 2008.x it might be trickier. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Om2008.x] external speakers still work after headphones being plugged
On Saturday 20 December 2008, Gonzalo Igartua wrote: > Hi, I'm using Om2008.9 and media players pythm and deforaos-player. Both > programs using mplayer. When I put the headphones are still listening to > the music from the internal speakers of my Neo FreeRunner. > > I have read some information on the net, but I don't see that the > discussion will arrive to any practical solution. > http://lists.openmoko.org/pipermail/community/2008-October/033270.html > > How can I do? For plugging the headphones stop sounding speakers for > mobile Om2008.x doesn't change alsa states when the headset is plugged in, but you can do it manually. alsactl -f /usr/share/openmoko/scenarios/headset.state restore To set it back to using the speaker replace headset.state with stereoout.state. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: SHR - Keyboard
On Thursday 18 December 2008, Carsten Haitzler wrote: > On Thu, 18 Dec 2008 14:49:50 +0000 Al Johnson > > > babbled: > > On Thursday 18 December 2008, clare johnstone wrote: > > > On Tue, Dec 16, 2008 at 8:28 PM, Paul wrote: > > > > Is there a way to make the keyboard pop up on demand, say for the > > > > terminal? > > > > > > Or did you just mean: press the tiny little mark at centre top of the > > > screen. A curtain 1/3 the size of the screen will wander down. At its > > > top right corner is the word "qwerty". if you press that a keyboard > > > will appear. > > > Later you can repeat to make the keyboard disappear. > > > > Yes, it is now frustratingly longwinded. The keyboard icon on the > > matchbox > > it's that way because slowly i'm expecting toolkits to be able to > auto-popup or apps - it's still there, but i moved it away to make more > room on the top bar for other things. it's laid out by theme so it can be > changed - but the default is aimed more at the "state of things how they > should be right now" I'm finding that I have to manually pull up the keyboard more often now than I used to, not less. Rather like the original keyboard discussion I agree with the theory, but in practise things aren't there yet. > > panel is much better in my opinion. Even better would be a keyboard icon > > that brought up the default keyboard if tapped, but if held would pop up > > a list of available keyboards or layouts. > > that can be done - though it duplicates the layout selector on the kbd > itself If the 'correct' layout would appear automatically every time it wouldn't be an issue. Until that happens the duplication allows manual selection of the 'correct' keyboard for the situation with a tap-hold-drag rather than tap (bring up keyboard) tap (bring up layout selection) scroll (as it seems to add scroll bars whether needed or not) tap (to select layout). There is of course the argument that if you make the keyboard too easy nobody will ever fix the apps ;-) > > It can be a little distracting, but it doesn't seem to compromapp-emulation/emul-linux-x86-java-1.5.0.17ise > > performance. It seems to keep up with ~4 characters per second - as fast > > as I can hit characters in short bursts anyway. Sometimes I get > > characters from a long way from where I tapped, but I suspect that's the > > touchscreen driver causing problems since I have the same problem with > > the matchbox keyboard. > > if you happen to have both fingers pressed at once (as you haven't released > 1 before pressing the other) this will happen. this is just unfortunately > part of life with a single-touch resistive touchsrceen. (i can come up with > hackish workarounds like extrapolating sudden moves to be a new press > somewhere else in the tslib driver... but now you're in magic voodoo land > and really.. you just should have multitouch). This is with a single finger or stylus, and a definite release before the next tap. This sort of operation works without problem on a Psion 5, another device with a resistive touchscreen and still my reference device in many respects. > > I suspect part of the reason people tend to dislike the qtopia and > > default illume keyboards is that by default they don't do what we expect, > > and it isn't obvious what they are doing. The matchbox keyboard is just > > an onscreen representation of a familiar keyboard, and behaves as we > > expect. It doesn't require any extra knowledge to get it to do what we > > want. The same could be said of the illume terminal layout, but that > > isn't the default. > > also one could argue that the invers could be the case. i am trying to > answer and sms and do nothing but yell at this tiny pokey keyboard i can > barely hit with a finger - and the device has no place for a stylus (and > the one that comes with it is so huge i wouldn't be seen dead carrying it). > :) you can't win. you make lot A happy, then lot B unhappy. thats why there > are multiple layouts to at least give the options to both. the default lean > is towards using it as a PHONE - not as a terminal. i would assume the > nerds have enough braincells to rub together to switch layout :) I never said it was easy ;-) The corrective keyboard and the alternate keyboard layouts are hugely better than the matchbox keyboard, but there is a barrier to entry that the matchbox keyboard doesn't have. The matchbox keyboard is intuitive but ultimately limited as an input method as you say. The challenge is to lower the initial barrier for the illume keyboard so that more people get to see the advantages on the other side rather than giving up and ditching it for the matchbox one, only to run into its limitations at a later date. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: SHR - Keyboard
On Thursday 18 December 2008, clare johnstone wrote: > On Tue, Dec 16, 2008 at 8:28 PM, Paul wrote: > > Is there a way to make the keyboard pop up on demand, say for the > > terminal? > > Or did you just mean: press the tiny little mark at centre top of the > screen. A curtain 1/3 the size of the screen will wander down. At its top > right corner is the word "qwerty". if you press that a keyboard will > appear. > Later you can repeat to make the keyboard disappear. Yes, it is now frustratingly longwinded. The keyboard icon on the matchbox panel is much better in my opinion. Even better would be a keyboard icon that brought up the default keyboard if tapped, but if held would pop up a list of available keyboards or layouts. > The keyboard has a sign in some oriental language at its top right > which causes changes in it. Basically 3 possibles, of which the third > can be quite useful if you can get it to respond. It is "ABC" with the characters overlapping slightly. It needn't be 3 choices either - you can add or remove keyboard layouts as you wish. You could remove all but the terminal layout if that's the only one you want. People have produced alternative layouts better suited to other languages too. The top left lets you pick the dictionary to be used for the corrective input, so you could have multiple languages available. > It has the habit of enlarging its characters > when they are pressed which may be helpful when trying to use fingers > to type on it but slows it. It can be a little distracting, but it doesn't seem to compromise performance. It seems to keep up with ~4 characters per second - as fast as I can hit characters in short bursts anyway. Sometimes I get characters from a long way from where I tapped, but I suspect that's the touchscreen driver causing problems since I have the same problem with the matchbox keyboard. > It also at times develops a habit known as predictive. Corrective would be more accurate, and whether it is enabled depends on the keyboard layout. The icon in the top left will give you the full list of potentially matching words, with the exact string you entered always at the top. The quality of correction is heavily dependant on the dictionary, at least out of the box. The default english dictionary works well, but some have reported problems with german for example. To some extent this should be offset if you persevere as it adds spellings and word frequencies to your personal dictionary, > I have actually been shown how this can be made to work on a mobile > phone where it may have some value. Agreed. With the corrective layout I can enter text reasonably reliably one handed while walking. I wouldn't have a hope of doing this with the terminal layout, or with the matchbox keyboard. > Compared with ordinary "tab completion" in linux commands it is not > even a starter, and again is a distraction.. But for linux commands surely you would use the terminal layout, which doesn't have the corrective feature enabled, and use tab completion. > clare (who really likes the matchbox keyboard - remember that?. It is > used in the new "hackable"; > and with apologies to Rasterman; but I do feel strongly on these points.) Input method preferences are highly personal. Happily we have a choice of input methods, and Rasterman included the facility to use them. If you install the matchbox keyboard, or any other for that matter, it should appear in the list of selectable keyboards in the illume config (spanner icon). I suspect part of the reason people tend to dislike the qtopia and default illume keyboards is that by default they don't do what we expect, and it isn't obvious what they are doing. The matchbox keyboard is just an onscreen representation of a familiar keyboard, and behaves as we expect. It doesn't require any extra knowledge to get it to do what we want. The same could be said of the illume terminal layout, but that isn't the default. The qtopia and illume keyboards try to be better, as does the iPhone keyboard, but all require a bit of hidden knowledge to get them to work. Once you know their secrets they are as good as or better than the matchbox keyboard, but if you don't know the secrets then they are incredibly frustrating. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Other possible Echo Cause
On Tuesday 16 December 2008, Timo Juhani Lindfors wrote: > Paul writes: > > http://lists.openmoko.org/nabble.html#nabble-td1486414|a1518726 > > Could somebody please send me the message-id of this message or > alternatively a link that works without javascript? I only get empty > page in midori and starting firefox takes a long time. http://lists.openmoko.org/pipermail/community/2008-November/036068.html ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: SHR - GPRS
On Monday 15 December 2008, Paul wrote: > Thank you for your response. > > I honestly do not know where to begin. I am not receiving an error, > it's just not connecting. I did try the internet and it is not > connecting. fso-config-util.py just provides a GUI that passes parameters to org.freesmartphone.GSM.PDP.ActivateContext() and shows the output of the ContextStatus signal, in your case 'release'. I should probably make it more human-readable, but in the meantime you can find an explanation at http://docs.freesmartphone.org You should be able to enable logging for fso in /etc/frameworkd.conf if it isn't enabled already. After restarting frameworkd (reboot is easiest) you should be able to see debug output using logread -f. It may be worth checking the thread "[SHR] GPRS / FATAL: Error inserting ppp_mppe" on the community list as it seems to be covering similar ground. What's this about an extra number that you need to enter? Is there a documentation page you can point us to? > I downloaded a copy of fso-config-util.py, I am uncertain if there is > an official version of it. http://openmoko.truebox.co.uk/tools/fso/fso-config-util.py Unless someone's made an updated version I don't know about ;-) > Is there an official howto for SHR? Has anyone gotten to work with AT&T? > > Thanks > > On Mon, Dec 15, 2008 at 2:36 PM, D. Gassen wrote: > > Hm, I'm on FSO (somewhat close to FSO, I'm a bit scared to update ;-)) > > but I get the same error message in the logs. However, gprs works fine > > with me (T-Mobile, USA). > > > > Have you checked if GPRS is working despite this error message? > > > > Dirk > > > > On 15.12.2008, at 14:16, Paul wrote: > >> I know there are reports that GPRS does work with SHR. > >> > >> I've download the fso-config-util.py script and edited my apn > >> settings, although for cingular/at&t, there is another number its > >> supposed to dial but no place to put it in the script. When I hit > >> connect, it just says, release. > >> > >> Any advice? > >> > >> Thanks in advance. > >> -- > >> Paul > >> Email - pault...@gmail.com > >> > >> There were moments when he looked on evil simply as a mode through > >> which he could realize his conception of the beautiful. > >> Oscar Wilde - The Picture of Dorian Gray > >> > >> ___ > >> support mailing list > >> support@lists.openmoko.org > >> https://lists.openmoko.org/mailman/listinfo/support > > > > ___ > > support mailing list > > support@lists.openmoko.org > > https://lists.openmoko.org/mailman/listinfo/support ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Other possible Echo Cause
On Monday 15 December 2008, Paul wrote: > > It's possible, but the buzz is within the voice frequency range. If we > > could characterise the buzz sufficiently it may be possible to remove it > > by applying a suitable digital filter in the CPU, but a hardware fix is > > certainly preferable. > > I was thinking a software noise gate would be preferable since it > requires less computing. Also, anyone tried sound proofing the mic > with sound insulating foam to prevent the sound from traveling through > the phone? There's a noise gate in the Wolfson chip, but I never managed to get it working. The functions in the GSM chipset sound like a noise gate in operation too. A better low-computing method might be to monitor the GSM output and mute the mic if there is significant signal there. This approach is used by some VoIP handsets ad is very effective at preventing echo, but can be awkward as the other end can't hear when you interrupt them ;-) The mic has rubber around it which seals the gap between the mic and the case. I haven't tried modifying this. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sad Story
Neither are representatives of Openmoko. They have bought phones just as you and I have. I suspect that they are frustrated by this long and unproductive thread, and by your perceived attitude. You don't appear to be interested in getting solutions to whatever problems you may be having. Suggesting someone is lying when they try to correct your misunderstanding is just plain offencive where I come from, as are your unsubstantiated accusations about Openmoko and their staff. This may simply be a cultural misunderstanding, as is often the case on international lists, in which case I suggest you correct it now. On Monday 15 December 2008, Karthik Kumar wrote: > Is that how you reply as a company which makes a phone? We can't fix > it so go buy our competitors' closed phones? I'd expect better from > you (like saying, yes, we'll fix it) than buy our competitor's phone. > If i had bought the competitors' phone, i wouldn't be cribbing now > that i've bought your phone, right? > > Maybe Openmoko should trade in iPhones instead of Freerunners, > considering I already paid for a Freerunner. What do you think for > that for a response? > > On Mon, Dec 15, 2008 at 4:44 PM, arne anka wrote: > >> Karthik: > >> > >> I think I probably speak for a reasonable portion of the community when > >> I say this: > >> > >> Go buy an iphone. Put your FreeRunner on ebay. You'll like the iphone - > > > > +1 > > > > ___ > > support mailing list > > support@lists.openmoko.org > > https://lists.openmoko.org/mailman/listinfo/support > > ___ > support mailing list > support@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/support ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sad Story
On Monday 15 December 2008, Karthik Kumar wrote: > On Mon, Dec 15, 2008 at 5:35 AM, Stefan Monnier > > wrote: > >>>> There are still hardware problems that exist with almost every > >>>> freerunner out there (GPS signal levels, for one). I would like to > >>>> see them fixed by Openmoko, Inc. > >> > >> The kernel fix for GPS is a mere quirk. Ideally it should get fixed in > >> hardware. > > > > Huh? The kernel fix seems to work OK for those people who have old > > FRs. Newer FRs have a hardware fix. E.g. my FR doesn't need any > > kernel workaround. No need to wait for GTA03 to get a hardware fix. > > So, this kernel fix is a feature, according to Al Johnson? Then why do > they need a hardware fix? They don't. Neither of my Freerunners has the hardware fix, and the GPS works just fine with any kernel that includes the fix. > Unless I am missing something, this software > fix seems to be a lie. Or the hardware fix seems to be bogus anyway. You are missing something, so I will try to explain. The 'hardware fix' is a small capacitor from the SD clock line to ground, and was a quick response to the problem when the SD was discovered to be interfering with the GPS. This slows the transition between the digital high and low states, reducing the level of interference generated. Reducing the drive strength does the same thing, but through a slightly different mechanism, and doesn't require a soldering iron to make the change. Note that the hardware fix only reduces interference from the clock line. The kernel fix reduces interference from the other signal lines too. To understand the issues more fully I suggest you read up on the analogue properties of digital electronics, particularly in regard to the speed of transitions and their effect on EMI. > I have one of the earlier freerunners released, so I'm sure Openmoko > owes an explanation. Both hardware and software fixes were discussed extensively on the lists, and are in the list archive. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Other possible Echo Cause
On Monday 15 December 2008, Paul wrote: > I have been thinking about the possible causes for the echo bug. I > have a feeling that it's actually feedback and not an echo. I think > what's happening is the sound is being picked up by the mic and being > sent to the remote phone for an extra round of fun. I hadn't realised there was any doubt that this was the mechanism. > Does anyone know how I would start testing this? In particular, I > would like to try the following. > > 1. Disable the mic totally and raise the handset volume. I know the > handset volume is set by Control.4 values in gsmhandset.state file. I > would make some phone calls and have the remote party talk to see if > an echo occurs. If not echo occurs, well then we know the mic is part > of the cause. If you mute either the mic or the earpiece there is no echo. If you use the wired headset there is no echo. The level of echo is affected by both the mic gain and the earpiece level. Using the speakerphone gives much more echo, which is expected because the volume is higher and the speaker is close to the mic. > I also know that our telephone systems do not transmit the whole > audible frequency range. Is there a way to clip the audio from the > mic for phone calls? I think this would translate to > reduce/elimination of buzz. It's possible, but the buzz is within the voice frequency range. If we could characterise the buzz sufficiently it may be possible to remove it by applying a suitable digital filter in the CPU, but a hardware fix is certainly preferable. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sad Story
On Sunday 14 December 2008, arne anka wrote: > > 1. Recamping issue - http://docs.openmoko.org/trac/ticket/1024. > > I know it's hard and I presume people from TI aren't being helpful since > > solving this issue isn't going to be very profitable for them. Still, > > please, > > someone solve this! > > does the relased firmware not apply? The moko10 firmware was intended to fix #666 and appears to have been successful according to the majority of reports. It did not, and was not expected to, do anything about #1024. That is being worked on for the next firmware release. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sad Story
On Saturday 13 December 2008, Karthik Kumar wrote: > On Sat, Dec 13, 2008 at 9:53 PM, Stefan Monnier > > wrote: > >> There are still hardware problems that exist with almost every > >> freerunner out there (GPS signal levels, for one). I would like to > >> see them fixed by Openmoko, Inc. > > The kernel fix for GPS is a mere quirk. Ideally it should get fixed in > hardware. I am sure that Openmoko's GTA03 changes include a > replacement of the existing u-blox. Is Openmoko considering fixing the > GPS? You appear to be misinformed. The kernel fix enables the hardware SD drive strength control. This is _not_ a mere quirk - reducing EMI is one of the reasons hardware manufacturers include such a hardware feature. The early kernels had the drive strength hardcoded to the highest value which was higher than necessary in this hardware configuration, and caused interference problems. This was a software bug, and was fixed in later kernels by setting a lower default drive strength that is appropriate to the hardware implementation. This reduces EMI to the point that the ublox gps module performs to specification with the internal antenna even during writes to the SD, and generally outperforms my Garmin Geko 201. You may have been thinking of the earlier kernel fix which disabled the SD clock when it wasn't necessary, where previously it had been running continuously. This also reduced EMI when no data transfers were happening, but should be employed to reduce power consumption anyway. Both fixes are exposed as parameters in sysfs, so you can adjust the drive strength, and enable the clock permanently if you wish. There is a script in the wiki that will cycle through the possible settings recording TTFF so you can see the effects for yourself. Note that you need to disable any gps daemons before running it, and it will take a long time too run. When both are unassisted it also gets a fix faster and more reliably than a friend's N95. The N95 uses a different form of assistance, and when assisted it can get a fix faster than the GTA02, and in locations the GTA02 can't. I have yet to try the GTA02 assisted. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Testing build
On Tuesday 09 December 2008, Paul wrote: > I have tried out the testing image several times installing it several > ways, even flashing the latest image. > > Has anyone had any success with them? These images do not seem to be > able to connect to the gsm network. Need to know which distro you're asking about as FSO, SHR and OM (2008.x) all have testing images. Convention has it you should stick the distro(s) you're asking about in the subject line. It also helps to use the date of the image as the testing builds are updated daily, and breakages may only apply to certain dates. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [SHR] linphone without /usr/bin/linphone
On Tuesday 09 December 2008, Julien Cassignol wrote: > On Tue, Dec 9, 2008 at 1:32 AM, Joachim Ott <[EMAIL PROTECTED]> wrote: > > Yes, this install the commandline client. And the graphical client? When > > I click on the icon, it wants to execute linphone and not linphonec. > > None was built. Find a good one, or tell me what is the name of the bb > recipe for a good not CLI client, and I'll build it :-) linphone is a good lightweight client, but the bb version is rather out of date, and there's a dependency problem regarding libosip2 which needs to be a 2.x version. And we don't get the GUI. Someone had a working linphone 2.x with GUI, and patches to switch the alsa state for ringing and call pickup. Another option might be to use telepathy. This gives us a dbus API for IM and VoIP so we could add it directly to the voice and messaging GUIs. This cuts across the FSO call control interface somewhat though, as I understood that was intended to become a universal interface to voice calling methods. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: NAND flash Help?
You may have accidentally flashed over your uboot configuration. The link below may help. http://wiki.openmoko.org/wiki/Uboot#What_if_I_borked_my_bootloader_environment_and_don.27t_get_a_prompt_anymore.3F On Friday 05 December 2008, Peter OConnor wrote: > I have done that > > dfu-util -a u-boot -R -D gta02v5_and_up-u-boot.bin > dfu-util -a kernel -R -D Om2008.9-gta02-20081106.uImage.bin > dfu-util -a rootfs -R -D Om2008.9-gta02-20081117.rootfs.jffs2 > > I still get the same thing... Any help would be nice. Specific > instructions would not hurt either... > > > Message: 9 > Date: Fri, 5 Dec 2008 08:51:56 +0100 > From: "Joachim Ott" <[EMAIL PROTECTED]> > Subject: Re: NAND flash Help? > To: "Support for Openmoko Device Owners" > Message-ID: ><[EMAIL PROTECTED]> > Content-Type: text/plain; charset="utf-8" > > 2008/12/5 Peter OConnor <[EMAIL PROTECTED]> > > > I need some direction on fixing my NAND flash. If I try just using the > > power button to turn on the phone I get the ROOT MENU (NAND) Boot option. > > Then selecting Boot it locks up. > > Press and hold AUX, then Power. This will put you to "BOOT MENU (NOR)". > From there you can use dfu-util to flash. > -- next part -- ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Re-registering to GSM network
On Thursday 04 December 2008, Hans Petter Selasky wrote: > Hi, > > Was there a patch for this issue? > > I suddenly found out that people were not able to call me, and had to > indulge in another cell-phone :-) There is a workaround that should be in recent versions of most distros. This should cut in for an hour if frequent reregistrations are detected. FSO also has a config option to enable it permanently as some people suffering reregistration don't have it often enough to trigger the detection, but still have problems with it. Stick the setting below in the [ogsmd] section of /etc/frameworkd.conf ti_calypso_deep_sleep = never If you want more details search the lists for AT%SLEEP=2 or some suitable substring. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: why is my freerunner magnetic?
On Tuesday 02 December 2008, Robin Paulson wrote: > 2008/12/2 Joel Newkirk <[EMAIL PROTECTED]>: > >> 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... ;) > > not in the freerunner: > > http://wiki.openmoko.org/wiki/Neo_1973_vs_Neo_FreeRunner The location you mention may be closer to the vibrate motor than the speaker. Both probably have some stray magnetic field though. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Crostalk of voice input and output in openmoko FreeRunner
On Monday 01 December 2008, Paul wrote: > I can send you some tomato juice, but the bug still exists. > > I am trying to pin down the details. Perhaps some package got updated > somewhere? > > I also hear that there are different hardware versions which require > different gsmhandset.state files. Any more info? This relates to the a7 hardware revision which AFAIK hasn't shipped yet. IIRC it has modifications around the handset mic. This reduces or removes the buzz problem, but needs more gain to get the mic volume to an acceptable level. http://lists.openmoko.org/pipermail/devel/2008-November/003312.html > Thanks. > > On Mon, Nov 24, 2008 at 10:53 AM, Alejandro Alonso Fernández > > <[EMAIL PROTECTED]> wrote: > > Uooou!, tahnks! but I prefer tomato juice!!! :D > > > > 2008/11/24 Paul <[EMAIL PROTECTED]> > > > >> Alejandro, > >> > >> Thank you, my preliminary tests are turning up good so far, I need to > >> call a couple of other people on other networks to finalize the > >> testing. > >> > >> Check your email for me as I will be contacting you about your beers > >> if all goes well. > >> > >> On Mon, Nov 24, 2008 at 10:26 AM, Alejandro Alonso Fernández > >> > >> <[EMAIL PROTECTED]> wrote: > >> > Well, that patch only works in FSO and SHR, in OM2008 things are a bit > >> > different but you can do this > >> > http://lists.openmoko.org/pipermail/community/2008-October/033312.html > >> > (I > >> > tried and it works!!! ^^) > >> > > >> > 2008/11/24 Paul <[EMAIL PROTECTED]> > >> > > >> >> I will send him a case of beer (or monetary equivalent if not > >> >> feasible). My conditions: I will need to test the patch and verify > >> >> that it works. It needs to work on OM 2008.9 preferably but I will > >> >> settle for FSO. > >> >> > >> >> /usr/lib/python2.5/site- > >> >> packages/framework/subsystems/ogsmd/modems/ti_calypso/unsolicited.py > >> >> > >> >> The file isn't on my Freerunner OM 2008.9 (November build). Is this > >> >> a FSO only thing? Before I reflash, what are the solutions for OM, > >> >> if any? > >> >> > >> >> On Mon, Nov 24, 2008 at 9:55 AM, Bobby Martin > >> >> <[EMAIL PROTECTED]> > >> >> > >> >> wrote: > >> >> > On Mon, Nov 24, 2008 at 2:08 AM, polz <[EMAIL PROTECTED]> wrote: > >> >> >> On Sunday 23 November 2008 23:33:59 Paul wrote: > >> >> > > >> >> > > >> >> > > >> >> >> P.S. if anyone from Openmoko(the company) is reading this, someone > >> >> >> should > >> >> >> send > >> >> >> Ainulindale on #openmoko a case of beer or something. > >> >> > > >> >> > Hear, hear!! > >> >> > > >> >> > > >> >> > > >> >> > ___ > >> >> > support mailing list > >> >> > support@lists.openmoko.org > >> >> > https://lists.openmoko.org/mailman/listinfo/support > >> >> > >> >> -- > >> >> Paul > >> >> Email - [EMAIL PROTECTED] > >> >> > >> >> There were moments when he looked on evil simply as a mode through > >> >> which he could realize his conception of the beautiful. > >> >> Oscar Wilde - The Picture of Dorian Gray > >> > >> -- > >> Paul > >> Email - [EMAIL PROTECTED] > >> > >> There were moments when he looked on evil simply as a mode through > >> which he could realize his conception of the beautiful. > >> Oscar Wilde - The Picture of Dorian Gray ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: battery life problem
On Wednesday 24 September 2008, Robert Norton wrote: > 2008/9/24 Al Johnson <[EMAIL PROTECTED]>: > > On Wednesday 24 September 2008, Gothnet wrote: > >> Pietro "m0nt0" Montorfano wrote: > >> > Robert Norton ha scritto: > >> >> I observed the same problem with my newly arrived freerunner running > >> >> om2008.8 update. I fiddled with the wifi then did ifdown eth0 and > >> >> suspend. Bluetooth, wifi and GPS all set to off in settings. Less > >> >> than 24h later the neo would not turn on (thankfully there was enough > >> >> charge left to boot and start charging when I returned home). > >> > > >> > Yeah, anyone know anything to see which of the many things on the FR > >> > is draining my battery? > >> > >> I'd like to add my voice to this lot, I've been getting in the order of > >> 8-12 hours of battery life with minimal conversation or testing and > >> everything switched to off. I even looked to see if there was a higher > >> capacity battery available (there isn't). > >> > >> It seems to be a little better with up to date Om2008.08, but not a hell > >> of a lot. > >> > >> Any tips on diagnostics to run? > > > > My money's on the GSM module. I switched the GSM off because there was no > > SIM in, suspended the phone on a Friday afternoon and powered it up on > > Monday to find ~70% battery remaining. With GSM enabled and SIM inserted > > battery life is variable; sometimes it'll make it through the night with > > a fair bit of charge left, and other times it's dead by morning. I know > > that I sometimes get persistent, frequent GSM reregistration, and from > > the interference it generates on the PC speakers I know this is probably > > drawing a fair bit of current. The reregistration is a persistent, > > intermittent (for me) and as yet unexplained problem: > >http://docs.openmoko.org/trac/ticket/1024 > > That's interesting! I didn't have a SIM card inserted so perhaps that > is part of it. Perhaps the GSM module is upping the power in order to > try and register but never succeeds because obviously it can't without > a SIM (just hand waving here, I know nothing about how this all > works)? > > How did you turn off the GSM module? This is with a 2007.2 based image, so the gsm icon could be used to turn it off. I wouldn't expect it to try registering with no SIM, but you never know. I didn't have the SIM in so I thought I would turn gsm off. I was expecting it to be dead on the monday. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: battery life problem
On Wednesday 24 September 2008, Gothnet wrote: > Pietro "m0nt0" Montorfano wrote: > > Robert Norton ha scritto: > >> I observed the same problem with my newly arrived freerunner running > >> om2008.8 update. I fiddled with the wifi then did ifdown eth0 and > >> suspend. Bluetooth, wifi and GPS all set to off in settings. Less than > >> 24h later the neo would not turn on (thankfully there was enough > >> charge left to boot and start charging when I returned home). > > > > Yeah, anyone know anything to see which of the many things on the FR is > > draining my battery? > > I'd like to add my voice to this lot, I've been getting in the order of > 8-12 hours of battery life with minimal conversation or testing and > everything switched to off. I even looked to see if there was a higher > capacity battery available (there isn't). > > It seems to be a little better with up to date Om2008.08, but not a hell of > a lot. > > Any tips on diagnostics to run? My money's on the GSM module. I switched the GSM off because there was no SIM in, suspended the phone on a Friday afternoon and powered it up on Monday to find ~70% battery remaining. With GSM enabled and SIM inserted battery life is variable; sometimes it'll make it through the night with a fair bit of charge left, and other times it's dead by morning. I know that I sometimes get persistent, frequent GSM reregistration, and from the interference it generates on the PC speakers I know this is probably drawing a fair bit of current. The reregistration is a persistent, intermittent (for me) and as yet unexplained problem: http://docs.openmoko.org/trac/ticket/1024 ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sound quality in calls.
On Monday 22 September 2008, Angus Ainslie wrote: > On Sun, Sep 21, 2008 at 4:55 PM, Vasco Névoa <[EMAIL PROTECTED]> wrote: > > Much better now. :) > > Say, what happens to the changed values when we terminate the phone > > call? They are lost, right? I mean, the volume values should be reset by > > the "*.state" files... > > Currently they are lost. I was thinking of adding a save button to screen . Sounds good. A 'reset to defaults' would be good to get back to some sane values too. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Headphone event
On Saturday 20 September 2008, Armin ranjbar wrote: > On Fri, 19 Sep 2008 13:33:49 +0430 > > Armin ranjbar <[EMAIL PROTECTED]> wrote: > > Do you get headphone event when you insert one under /dev/input/event0 ? > > mine returns nothing . > > Can someone with om.2008+ do this test ? > > cat /dev/input/event0 > and insert headphone Using Fat_and_Dirty_OM.200808-updates.20080913.rootfs.tar.gz on SD I get some output on insertion and some more on removal. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: 2007.2: openmoko-messages segfault
On Thursday 18 September 2008, Risto H. Kurppa wrote: > hi! > > I've been using 2007.2 pretty much the whole time since I got the > phone (tried, qtopia & debian but 2007.2 was most suitable for me). If nobody has an answer to this one you might like to look at SHR. There isn't a release yet, but the idea is to port the 2007.2 UI to the FSO API. http://wiki.openmoko.org/wiki/Stable_Hybrid_Release ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sound quality in calls.
On Thursday 18 September 2008, Marco Trevisan (Treviño) wrote: > Tom Yates wrote: > > i experimented yesterday with turning on the hardware echo cancellation, > > and that worked for one call (allowed me to increase Speaker Playback > > Volume to 117) but then things went back to being very echoey. so unless > > i'm willing to have a minicom session at the beginning of every call, > > that's not usable right now; i'll have to wait until the AT%N0187 is > > integrated into qtopia's call-handling logic. > > So do you think that calling that AT command before of doing/answering a > call would improve the sound quality? > If it is, I guess this could be done quite easily in the code... So if I > find some free time, I'll try it! It was persistent over 2 calls when I tried it in FSO, but it certainly shouldn't do any harm. I used mickeyterm to enable and disable it mid call to check that call to call variability wasn't playing a part. It may also be worth trying some of the other settings. From the hardware list post: "0083" "Short AEC is active" "0283" "Long AEC is active" "028B" "Long AEC -6 dB is active" "0293" "Long AEC -12 dB is active" "029B" "Long AEC -18 dB is active" "0105" "Noise reduction is active" "0125" "Noise reduction -6 dB is active" "0145" "Noise reduction -12 dB is active" "0165" "Noise reduction -18 dB is active" "0187" "Both AEC and Noise reduction are active" "0001" "AEC and Noise reduction are unactivated" These are bitmasked. From LSB upward the usage appears to be: LSB - always true AEC (short or long) NR -6dB on AEC -12dB on AEC -6dB on NR -12dB on NR AEC (short or long) NR Long AEC So far AFAIK only 0001 (nothing) and 0187 (short AEC and NR) have been tried. What does Long AEC do? Or -XdB for AEC and NR? Do other combinations than those listed work? Does 0387 give us Long AEC and NR? ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sound quality in calls.
On Thursday 18 September 2008, Armin ranjbar wrote: > On Thu, 18 Sep 2008 10:50:03 +0100 > > Al Johnson <[EMAIL PROTECTED]> wrote: > > Thanks. This sort of question is _much_ more likely to get a useful > > answer. > > > > I've not looked into this directly, but IIRC there were reports of > > pulseaudio doing sample rate conversion on almost everything that was > > played, munching CPU in the process and not necessarily leaving enough > > for smooth decode of the media file. The media player in 2007.2 was > > apparently affected by this, but if patched to use alsa directly it was > > fine. I can't verify this as I had gstreamer errors with the mp3 I tried > > it with. I think pulseaudio has been dropped from 2008.8 and FSO because > > of this. I don't know what the situation is with qtopia, but if you run > > top while playing a file you should see if anything's hogging CPU. I > > suggest you search the list archives for the original reports on this > > issue as they probably contain details I've forgotten or got wrong ;-) > > > > mplayer by default plays directly through alsa so isn't affected by the > > sound server issues. That you say sound is nearly perfect in this case > > shows the hardware limitation isn't really the issue. > > > > I haven't looked closely at the whole media playback issue so I don't > > know what the best solution is. If you're lucky someone who does might > > read this, but you may be better off reposting with a more appropriate > > subject line. > > Already filed a bug on this : > http://docs.openmoko.org/trac/ticket/1956 You probably won't get much response to that bug report, first because it lacks sufficient detail, and second because it's against 2007.2 which is now more or less unsupported by Openmoko. For improved bug reporting see the links below. I thought the policy was supposed to be linked from the front page of the bug tracker, but it seems not to be. Details like exact version numbers and the repositories the packages came from are important for duplicating your bug and working out why it doesn't happen for someone else. http://wiki.openmoko.org/wiki/Bug_Filing_Policy http://www.mail-archive.com/devel%40lists.openmoko.org/msg01462.html 2007.2 is being converted to use the FSO interfaces to make the 'Stable Hybrid Release' (SHR). So far there is no release image for this project, but they may have more ideas on this. > the Mplayer on om2008 is directly connected to OSS not alsa, when i -ao > alsa it becomes 'very sensible' to loads , audio stop and resumes even > after each characters into terminals , strange ... Have you had a look at CPU load? Is this repeatable? This is different to the bug report. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sound quality in calls.
On Thursday 18 September 2008, Armin ranjbar wrote: > On Wed, 17 Sep 2008 21:29:53 +0100 > Al Johnson <[EMAIL PROTECTED]> wrote: > > > I can understand your point now , this is my problem : > > VERY bad sound quality using Headset under Qtopia and > openmoko mediaplayer , lots of Strange noises , echoes , and totally > unlistenable quality . > > you know what is strange about it ? using Mplayer sound quality is Nearly > perfect ( except for lack of bass , which is not very important ) , any > idea ?! > > is this the issue with pulse audio and or soundserver ? Thanks. This sort of question is _much_ more likely to get a useful answer. I've not looked into this directly, but IIRC there were reports of pulseaudio doing sample rate conversion on almost everything that was played, munching CPU in the process and not necessarily leaving enough for smooth decode of the media file. The media player in 2007.2 was apparently affected by this, but if patched to use alsa directly it was fine. I can't verify this as I had gstreamer errors with the mp3 I tried it with. I think pulseaudio has been dropped from 2008.8 and FSO because of this. I don't know what the situation is with qtopia, but if you run top while playing a file you should see if anything's hogging CPU. I suggest you search the list archives for the original reports on this issue as they probably contain details I've forgotten or got wrong ;-) mplayer by default plays directly through alsa so isn't affected by the sound server issues. That you say sound is nearly perfect in this case shows the hardware limitation isn't really the issue. I haven't looked closely at the whole media playback issue so I don't know what the best solution is. If you're lucky someone who does might read this, but you may be better off reposting with a more appropriate subject line. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sound quality in calls.
On Wednesday 17 September 2008, Angus Ainslie wrote: > On Wed, Sep 17, 2008 at 6:07 AM, Al Johnson > > <[EMAIL PROTECTED]>wrote: > > Controls affecting handset mic volume for GSM: > > Control 48: "Mic2 Capture Volume" > > Control 12: "Mono Sidetone Playback Volume" > > Control 5: "Mono Playback Volume" > > > > Controls affecting wired headset mic volume for GSM: > > Control 49: "Mic1 Capture Volume" > > Control 12: "Mono Sidetone Playback Volume" > > Control 5: "Mono Playback Volume" > > I've written a python mixer to control the mic volumes for the various > headsets. The speaker volumes will be added when I trace their path through > the wolfson. Thanks for doing the script. Here are some more controls if you haven't found them already. Controls affecting bluetooth mic volume for GSM: Control 13: "Mono Voice Playback Volume" Control 5: "Mono Playback Volume" Controls affecting handset earpiece volume for GSM: Control 6: "Bypass Playback Volume" Control 4: "Speaker Playback Volume" Controls affecting wired headset earpiece volume for GSM: Control 6: "Bypass Playback Volume" Control 3: "Headphone Playback Volume" Controls affecting bluetooth earpiece volume for GSM: ? I suppose we should have same for VoIP too. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: What's wrong with gpsd
On Wednesday 17 September 2008, Atilla Filiz wrote: > These happened with FSO milestone 2 and 3 > Case 1:I turn on GPS, start gpsd and start Tango gps. Even if I read the > NMEA stamps with "cat /dev/ttySAC1", TangoGPS still reports 0 satellites > and gps tome of 1 Jan 1970 > > Case 2: > Turn on GPS, start gpsd, run "xgps 192.168.0.202", and xgps hangs > > Case 3: > Turn on GPS, instead of running gpsd, shovel NMEA using "nc 192.168.0.200 < > /dev/ttySAC1" and run gpsd on my PC, then xgps runs normally. > > So something is definitely wrong with gpsd on FR. Am I the only one with > this? The problem is that you're running gpsd on FSO! As part of the framework FSO provides a gps daemon (ogpsd?) that uses the gypsy dbus interface. There's a compatibility package that lets it output in gpsd format so that apps expecting gpsd will also work - you should be able to find it with: opkg list |grep gps If you run gpsd at the same time as the FSO daemon they will compete for the serial port, probably breaking them both. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sound quality in calls.
On Wednesday 17 September 2008, Daniel Hedblom wrote: > Hi, > > Thanks! > > Now i get pretty decent volume. Albeit with static bzz but people can > atleast hear me. I think this would be nice to have on the Wiki since > most references about mic talks about changing mic2 in alsa and > nothing about "Mono Playback Volume". Maybe someone with more insight > could write up a quickie? Controls affecting handset mic volume for GSM: Control 48: "Mic2 Capture Volume" Control 12: "Mono Sidetone Playback Volume" Control 5: "Mono Playback Volume" Controls affecting wired headset mic volume for GSM: Control 49: "Mic1 Capture Volume" Control 12: "Mono Sidetone Playback Volume" Control 5: "Mono Playback Volume" ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sound quality in calls.
On Sunday 14 September 2008, Daniel Hedblom wrote: > Hi, > > 2008/9/14 Nicolas Dufresne <[EMAIL PROTECTED]>: > > Is the noise worst when put your finger on the audio jack ? > > Its worse depending on how i hold the phone but never good, just less > or more static. The real problem is the volume level thats turned down > so low people cant hear me at all. > > This looks like > > > the famous buzzing noize which is described here as a hardware bug mixed > > with bad alsa settings. > > Is this why the mic is turned down so low? The mic is low to reduce echo. With recent releases enabling the echo suppression in the GSM chipset you should be able to increase the mic level without getting echo. > > http://lists.openmoko.org/pipermail/hardware/2008-August/000415.html > > > > > > Le dimanche 14 septembre 2008 à 01:42 +0200, Daniel Hedblom a écrit : > > > > Well, i have tried 2008.7, Qtopia, FSO milestone 2 and 3 and debian. > > > > The sound has been described as if i sit in a barrel. Its very low > > with much interferance and echos. Im beginning to suspect somethings > > wrong with the actual hardware. > > > > //danielh > > > > 2008/9/13 Al Johnson : > >> On Saturday 13 September 2008, Daniel Hedblom wrote: > >>> I have tried mucking about with alsa levels to get better sound in > >>> various dists for the Freerunner. I havent got good outgoing sound in > >>> any distribution, everyone i talk to complains. > >>> > >>> Is there any way to get decent outgoing sound thats described > >>> somewhere a bit in detail? There seems to be so many different > >>> answers, im getting a bit confused. > >> > >> You've supplied too few details. Which images from which dates have you > >> tried, > >> and what exactly is wrong with the audio? ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sound quality in calls.
On Saturday 13 September 2008, Daniel Hedblom wrote: > I have tried mucking about with alsa levels to get better sound in > various dists for the Freerunner. I havent got good outgoing sound in > any distribution, everyone i talk to complains. > > Is there any way to get decent outgoing sound thats described > somewhere a bit in detail? There seems to be so many different > answers, im getting a bit confused. You've supplied too few details. Which images from which dates have you tried, and what exactly is wrong with the audio? ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: gta02, debian, fso: pairing (and using) bleutooth headset?
On Tuesday 09 September 2008, Angus Ainslie wrote: > On Mon, Sep 8, 2008 at 3:41 PM, Brad Midgley <[EMAIL PROTECTED]> wrote: > > I've looked at the scripts. They're pretty inventive. > > Thanks > > I've updated the scripts and the mic is working now. It's still a little > noisy but that is just tuning. > > Angus Excellent news, nice work. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: gta02, debian, fso: pairing (and using) bleutooth headset?
On Monday 08 September 2008, Jim Morris wrote: > Angus Ainslie wrote: > > Alright I've updated the scripts to configure and attach to the headset. > > The bluetooth_pcm binary is no longer needed. > > > > http://wiki.openmoko.org/wiki/Manually_using_Bluetooth#Bluetooth_on_Freer > >unner > > > > I suspect the mic input still doesn't work with the current alsa state > > file, I'll be looking at that in the next week. I'm also going to update > > the scripts to automatically load the alsamixers. > > This is good work, thanks. > > It seems the BtHeadset.py will run indefinitely in an infinite loop at the > end. > > I suspect it needs to listen on a signal and exit when the call is over. > > Using mixed case file names when trying to type on an itty bitty keyboard > in terminal makes stuff hard ;) > > Please let us know when you get the Mike working. There are some suggested changes to the alsa state file in another post of mine in this thread. I don't have a bluetooth headset so I can't test them, and Angus is busy improving his scripts. If you've got things working so far then it would be great if you could test those changes too. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: gta02, debian, fso: pairing (and using) bleutooth headset?
On Monday 08 September 2008, Angus Ainslie wrote:
> On Mon, Sep 8, 2008 at 10:51 AM, Al Johnson
>
> <[EMAIL PROTECTED]>wrote:
> > Voice interface input (i.e. from Bluetooth) goes to the voice DAC, and
> > needs
> > routing to the MONO1 output for the GSM. You may need to adjust the
> > levels a
> > bit, but I think this will get you going. I don't have a bluetooth
> > headset to
> > test with myself. Control 5 also controls mic level into the GSM so you
> > may need to adjust that too.
> >
> >control.13 {
> >comment.access 'read write'
> >comment.type INTEGER
> >comment.count 1
> >comment.range '0 - 7'
> >iface MIXER
> >name 'Mono Voice Playback Volume'
> > - value 0
> > + value 7
> >}
> >
> >control.76 {
> >comment.access 'read write'
> >comment.type BOOLEAN
> >comment.count 1
> >iface MIXER
> >name 'Mono Mixer Voice Playback Switc'
> > - value false
> > + value true
> > }
>
> Thanks added those to the wiki.
>
> Angus
Does that mean it works?
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: gta02, debian, fso: pairing (and using) bleutooth headset?
On Monday 08 September 2008, Angus Ainslie wrote:
> Alright I've updated the scripts to configure and attach to the headset.
> The bluetooth_pcm binary is no longer needed.
>
> http://wiki.openmoko.org/wiki/Manually_using_Bluetooth#Bluetooth_on_Freerun
>ner
>
> I suspect the mic input still doesn't work with the current alsa state
> file, I'll be looking at that in the next week.
Voice interface input (i.e. from Bluetooth) goes to the voice DAC, and needs
routing to the MONO1 output for the GSM. You may need to adjust the levels a
bit, but I think this will get you going. I don't have a bluetooth headset to
test with myself. Control 5 also controls mic level into the GSM so you may
need to adjust that too.
control.13 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 7'
iface MIXER
name 'Mono Voice Playback Volume'
- value 0
+ value 7
}
control.76 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Mono Mixer Voice Playback Switc'
- value false
+ value true
}
> I'm also going to update
> the scripts to automatically load the alsamixers.
>
> Could someone at OM add python-pyalsaaudio to the feeds ?
>
> Angus
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: gta02, debian, fso: pairing (and using) bleutooth headset?
On Friday 05 September 2008, Jim Morris wrote: > Angus Ainslie wrote: > > OK reproduced a few times now. > > > > Some times the bluetooth/alsa/dbus gets into a state where this will not > > work so you should reboot to start everything fresh. > > > > I've created a new state file that prodices NOISY audio , I will be > > looking into the source of noisy and getting the mic path properly setup > > as well. > > > > http://handheldshell.com/gsm_headset.txt > > > > Pair the headset ( only needs doing once ) > > > > run > > > > ./BtHeadset.py > > > > You should hear static in the headset at this point. If not try > > rerunning BtHeadset.py. If you still don't have static reboot. > > > > start the phone call. Once connected > > > > alsactl restore 0 -f gsm_headset.txt > > ./bluetooth_pcm > > Good work, The step you did that I did not even think of was running the > bluetooth_pcm.c file. To be honest I don't really see why/how this should > even work. But as it is the only step that was different from what I did I > suppose it must be the missing link. It looks like it's configuring the Wolfson voice PCM interface to use the data format the Bluetooth chip is using, and opening the interfaces for read/write so that it's expecting the data to flow. It just seems like an odd thing to do because we're used to the CPU being the source/sink for the PCM data, not a separate device as it is in this case. > Do you know if the audio is being routed directly from GSM to BT or through > the CPU via PCM then into the BT via the USB interface? It should be GSM<->Wolfson<->BT without the CPU playing a part other than to set it up. I'm having trouble working out how anything gets to the GSM mic input though, as all of the 'Mono Mixer (whatever) Playback Switch'es (Controls 74 through 78) are set to false. GSM playback goes via the ALC mixer to the left ADC. > Thanks for working on this, I had given up! ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [2008.8] [bluetooth] No "pand" daemon?
On Thursday 04 September 2008, Vasco Névoa wrote: > Hi. > I can't find the "pand" (Personal Area Network daemon) on my system, and > I can't find which package installs it. > I'd like to get bluetooth networking going, but its not possible without > "pand". > Was it removed from the distro? Someone has a clue for me? hidd recently disappeared, and had apparently been deprecated for some time. I wonder if pand has gone the same way. It certainly looks as though there is now a dbus-based control method for networking as there is for input device. Perhaps this will be of some help: http://wiki.bluez.org/wiki/HOWTO/NetworkConnections ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Alsa scenarios , mixer
On Thursday 04 September 2008, Dale Maggee wrote: > > Anyway, this script is usefull when trying to check what's up with the > > sound, and that jack insertion do nothing on sound :( > > it does for me: > > [EMAIL PROTECTED]:~# ./findstate > Current statefile is: /usr/share/openmoko/scenarios/stereoout.state > > (plug in headset) > > [EMAIL PROTECTED]:~# ./findstate > Current statefile is: /usr/share/openmoko/scenarios/headset.state > [EMAIL PROTECTED]:~# > > also when I use the headset in a call it uses gsmheadset.state rather > than gsmhandset.state > > (I'm using 2007.2) Doesn't do it in 2008.8 though, and the bug report was closed as 'wontfix' http://docs.openmoko.org/trac/ticket/1442 ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
