Re: [Shr-User] Quick e-mail poll: Still using your Freerunner?
Risto H. Kurppa wrote: Do you use FR as your daily/primary phone? YES. It's my only phone for over a year. I did the buzzfix and gps cap myself and got no complaints there. Adjusting the call volume is a sorely missed feature, though. But the slowness of the software does tend to screw up things when more than one thing happens at the same time (simultaneous incoming calls, etc.) Do you use FR as your primary PDA? YES. GPS, password vault, the occasional Mokomaze. GPRS and WIFI are too unstable for any real connection, so no web or email. And bluetooth is just not there (no GUI == not there for the user). Does anyone else have trouble doing opkg ugrade over gprs? mine hangs after a bit. What distribution you run most of the time? SHR-U (currently the old one from September, which works stable enough as a phone.) The new Testing is quite broken, and I couldn't understand why the new Unstables where older than the Testing ones. Now that I see a lot of people is using the Unstable, it's probably meant to be like that -- and just opkg upgrade all the time. Will try it today... If you don't use FR as your daily phone/PDA, what phone did you change over to, and why? I haven't switched out because it is good enough as a simple working phone and a very basic GPS. Other than that, it is crap. I don't blame the community for the state of things; I think that Openmoko.com started by biting off much more than it could chew, failed to build a solid community, then realized the dead end which they put themselves into, and backed out on all of us into plan B. I understand the economics that forced OM to reboot and start over with the Wikireader, but I will always resent the fact that I spent 300 EUR on a badly designed and even worse tested hardware. I cannot forgive them for releasing this HW into the public without a fully patched kernel and drivers and a full list of known caveats after an honest effort to completely test the device. They somehow thought that time-to-market was more important than quality and reliability. Personally, I think there is no forgiveness for them because of this. Having said that, I am admired at this community that still keeps kicking the dead horse with a passion, and there is a small thread of hope inside my heart that this brick will someday fulfill at least half of its promises. And if it does, it will all be due to the work of these last few heroes - and I thank you so much. The Openmoko project is to me a disappointment as big as the cancellation of SG-1 and Firefly: there was still so much to do and say, but economics had the last word. Well, at least there are positive things left behind like the FSO and the colorful ecosystem of other distros and apps. Have a nice 2010 everyone!! :D May the source always be with you. Thank you :) r ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: future phones that you can hack. news.
I do understand the skepticism, but thinking about the apparent success a pseudo-open platform like Android is having near the manufacturers and users, I'd say there is a very good chance something groundbreaking (in terms of market attitude) may actually happen. Android is fierce competition, and others may take the plunge into openness just to fight it. It's a lesser evil choice for the manufacturers (or in this case, a lesser potential for losses in the near future). Carry on, people!! :) Just don't let them twist your values. ;) Fabian Schölzel wrote: 2009/11/18 Carsten Haitzler ras...@rasterman.com: Who it is - will wait for future announcements. What, when and where will also need to wait. How open it is, will also need to wait. But you can guess that if we are fiddling with it - it's already partly open. Sounds interesting! Please keep us informed! Cheers, Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Downgrading to QVGA is something that should have been done a long time ago. There's no point in trying to force a badly designed system. How do we do it? Which files must be changed? Citando Carsten Haitzler ras...@rasterman.com: On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin anthropophag...@gmail.com said: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of none. it's a hardware issue. you simply cant read or write to video ram faster than that. andy tried timing stuff all that happened was instability from memory. glamo is most likely also the cause for the cpu runnig at 400 not 500mhz. the extra load on the memory bus (because glamo is hooked there externally providing another addressable chip) probably caused the instability. remove it and there is a big change the cpu could run at 500mhz instead of 400. it's rated to do 500. (yes power consumption would go up - but it'd only be up while its on. when suspended it wont matter). data flowing through it? There's one neighbor unanswered thread with a render on the device - and this will then limit what you can render. evas can't be fully accelerated by the glamo. it has too many opretations. a bit like asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx chip ever was designed to do and you will hit software fallbacks. evas has multiple engnines. software (which is what is used - the 16bit renderer as opposed to the full 32bit one). it has xrender - if xrender were fully accelerated this should be better, but glamo cannot fully accelerate all the ops evas uses, so... it will rely on software fallbacks. thus slow down. my bet is you'll end up same speed as the pure software engine, or worse. aftera bunch of hard work you'll have gone nowhere. evas also has a gl and gles2 engine - but thats no use on glamo. it's gles1.1 and very limited (from memory texture size is 256x256 which is pretty useless for 2d as most data you deal with breaks these bounds). question on how to start the kernel with qvga resolution. Aside of no need to do that - just configure x for qgva. :) this, what can be reduced, for example amount of available colours (256 or even 16)? And if this [too] low throughput only of video memory channel? 256 won't help. it increases complexity and really reduces display quality through the floor. the best best is qvga 16bpp. its simple. it doesn't require any hard work. it is actually the most common resolution for most phones and devices out there so the software is more portable if you work on that (and then higher). but... in the past everyone has moaned and complained and refused to use it, and insisted on their vga resolution... and then complained about speed. if people don't believe me that the gta02 is just plain a bad bit of hardware and you have few choices here's some examples. here'es an ooold efl demo app i did: http://www.rasterman.com/files/eem.avi and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, qvga(240x320). it's from like 2001/2002 (from memory). its ancient. and watch it run evas: http://www.rasterman.com/files/eem-live.avi here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m ram, and 800x480 (higher res than gta02): http://www.rasterman.com/files/ello-elementary-smartq5.mp4 everywhere i look... theres much better hardware. if you look at performance vs age of hardware (when it was released) gta02 is almost at the bottom of the pile. :( you simply have a bad piece of hardware if you want graphics performance. as soon as you acknowledge that and either downgrade the device resolution for example to bring it in line with its performance, or just use different hardware, the better life will be :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi doesn't read my /boot/append-GTA02
Then I'd say this is a very desirable feature (kernel parameters when booting from flash), if and when anyone tinkers with Qi again. Citando Paul Fertser fercer...@gmail.com: Vasco Névoa vasco.ne...@sapo.pt writes: I'm booting from Flash, not SDcard. Shouldn't the /boot/append file work the same? If it doesn't, where are the kernel parameters defined? Qi can't read jffs2, in this case kernel parameters are hardcoded. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi doesn't read my /boot/append-GTA02
I'm booting from Flash, not SDcard. Shouldn't the /boot/append file work the same? If it doesn't, where are the kernel parameters defined? Paul Fertser escreveu: Vasco Névoa vasco.ne...@sapo.pt writes: I'd like some help here, please. dmesg doesn't give me any clues. I removed the quiet splash from /boot/append-GTA02 and added glamo_mci.sd_drive=5, but none of it is sticking. It's ignoring the file altogether, AFAICT. Are you sure you're booting from SD? And that all you parameters are on the first line in that file? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR clock reset
I've started experiencing the same in the last few days. The Neo's clock had always been impeccably correct, until now. Now it was half an hour late and I set it by hand. It appears the clock is drifting, and otimed isn't keeping it in sync with the GSM. The only hints in frameworkd.log are: 2009.10.01 18:05:25.88 otimed INFO loaded timesources [GPSTimeSource, NTPTimeSource checking 134.169.172.1 every 600 seconds] 2009.10.01 18:05:25.124 otimed INFO loaded zonesources [GSMZoneSource] 2009.10.01 18:05:25.138 frameworkd.subsystem INFO subsystem otimed took 1.53 seconds to startup 2009.10.01 18:06:27.163 otimed INFO GSM: multiple zones found 2009.10.01 18:06:27.357 otimed INFO GSM: multiple zones found 2009.10.01 18:16:39.457 otimed INFO GSM: multiple zones found 2009.10.01 18:16:49.835 otimed INFO GSM: multiple zones found 2009.10.01 19:18:44.462 otimed INFO GSM: multiple zones found 2009.10.01 19:19:20.392 otimed INFO GSM: multiple zones found 2009.10.01 19:19:48.627 otimed INFO GSM: multiple zones found 2009.10.01 19:20:40.194 otimed INFO GSM: multiple zones found 2009.10.01 19:20:58.312 otimed INFO GSM: multiple zones found 2009.10.01 20:49:58.117 otimed INFO GSM: multiple zones found 2009.10.01 20:53:14.628 otimed INFO GSM: multiple zones found 2009.10.01 22:18:28.542 otimed INFO GSM: multiple zones found 2009.10.01 22:48:41.491 otimed INFO GSM: multiple zones found Does this GSM: multiple zones found situation create a problem? I looked at the hwclock, but it seems it's not even in use / not related to the time shown to user: r...@om-gta02 ~ $ hwclock -l Thu Oct 1 21:52:35 2009 0.00 seconds r...@om-gta02 ~ $ date Thu Oct 1 23:15:20 WEST 2009 Any hints on what the problem is? Vikas Saurabh escreveu: Timezone from GSM is already implemented for ages ;) I have often got wrong timezones reported by cell (thereby resetting my phone's clock and making me reach late somewhere :(...but thats a different story) I was wondering if shr-settings can get something like: Use cell timezone: * yes * no * ask --Vikas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Qi doesn't read my /boot/append-GTA02
I'd like some help here, please. dmesg doesn't give me any clues. I removed the quiet splash from /boot/append-GTA02 and added glamo_mci.sd_drive=5, but none of it is sticking. It's ignoring the file altogether, AFAICT. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How does well does this community work?
That's a though question, especially due to the differences between a car and a phone. :) When it comes to pure Community building, IMHO the leaders seem to be Ubuntu; so you should probably talk to Jono Bacon or read his book. ;) Regarding the Openmoko community, I think it works better now that we don't expect anything from Openmoko the company -- this has freed everybody to assert their own targets and roads, and get down and dirty instead of waiting for the next disclosure. So, not having a benevolent dictator over the community makes it proliferate and flourish. On the other hand, we now have almost as many distributions as we have phones out there. ;) And many of the applications are being redundantly developed in parallel, instead of collaboration. So, my humble advice to you: if 40fires wants a coherent community, focused on a small set of defined goals, you must be the benevolent dictator and you must have a single communication channel that is extremely clear (see linux or perl); if on the contrary, you seek variety, chaotic innovation, and surprise, then just throw it up on as many channels as you like and watch the feeding frenzy. :) BTW, congratulations on the project. The world needs it. Roland Whitehead escreveu: I am working with the 40 Fires Foundation [http://www.40fires.org] to try to build a framework for the development of open source hardware. You might have heard that the first project is the hyrban car - a car powered by a hydrogen fuel cell - the prototype of which was revealed by Riversimple [http://www.riversimple.com] earlier in the summer and whose designs have been licensed to 40 Fires. We have had input from Mozilla and other software foundations but of course the design of something like a car is a little harder to manage as an open source project. Openmoko.org is frequently raised in discussions and has lead me to push forward a wiki, mailing list and nabble based forums. Before we commit to this, how well do you think that this technology serves the Openmoko community? If you had the chance to build a community for the development of the Openmoko (hardware as well as software) what would you do and why? TIA Roland ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR - Latest unstable] opkg not found!
Some genius in a high ground took upon himself to rename it opkg-cl, therefore breaking our beloved scripts. Seek and ye shall find. Citando Tony Berth tonybe...@googlemail.com: Hallo, I got the latest SHR unstable and when trying to run 'opkg' I get: r...@om-gta02 ~ $ opkg -sh: opkg: not found --- How come? Thanks Tony ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR - Latest unstable] opkg not found!
Ok, then, I apologize. Citando Sebastian Krzyszkowiak seba.d...@gmail.com: On 8/11/09, Vasco Névoa vasco.ne...@sapo.pt wrote: Some genius in a high ground took upon himself to rename it opkg-cl, therefore breaking our beloved scripts. Seek and ye shall find. That's not renaming by some genius. That's just bug about missing opkg symlink to opkg-cl. opkg binary was in fact always named opkg-cli, with opkg symlink pointing to it. It will be fixed soon. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fixing bug #1024 successful reports?
I've been following this discussion from a distance, not paying much attention, but I'd like to warn that this fix is better done by replacing the original capacitor. One should avoid putting wires inside an RF can, especially if they run towards the outside of the can. It ruins the can shielding purpose... you're probably setting yourself up for some other different problem derived from RF interference after you do that... Citando Thomas HOCEDEZ thomas.hoce...@free.fr: Nice a picture is universally understandable ! Just a doubt I still have: why did you draw the c1009 outside the GSM antenna. regarding to this picture : http://n2.nabble.com/attachment/2971067/0/GSM_Modem_rework_try.JPG It is inside ... I'm a bit upset ... Bernd Prünster a écrit : Hi, We (french FR comunity) are trying to solve the #1024 bug. I put a 10uF SMD cap inside my GSM can, and I saw an increased battery life. your way to solve it is not as clear as I understand it. Correct me if i'm wrong : you only soldered the (+) of the c1009 cap to the GND ? or other way my english tell me you did : on wire on the (+) of the cap, on on the (-), and the two wires on the GND of the phone ? By advance thanks a lot. Thomas openmoko-fr.org freerunner.daily.free.fr maybe i screwd the description up i attatched a pic describing how i did it. basically solder a lacquer wire to c1009's (+) wich you will fit through the shielding can so you can add another c in parallel which can be any kind of tht electrolyte capacitor small enought to fit in the gsm antenna. ofcourse this c also needs to be connected to gnd, so take another peice of lacquer wire to connect the other capacitors (-) to gnd. hope it helps (pics will be postet within the next days) br ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Jokes updated
I couldn't resist the current talk about #1024 and capacitors... I made an update on the Jokespage of the wiki: Q. It looks like every HW problem in the Freerunner is solved with a larger capacitor. What do you think went wrong in the design process? A. I think it was a lack of capacity. :P ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner audio channels
I think you're all missing the point. David's initial post is a breath of fresh air into a long debated but (AFAIK) non-resolved issue. I deeply welcome his investigation into this subject, and support his questions (which I also would like to see answered). Although the issue of low playback volume is rather well controlled in our FRs, the issue of low recording volume for GSM transmission remains - with callers still complaining and going what? I didn't hear you... now and then, especially in (even slightly) noisy environments. The whole audio settings for GSM issue is _not_ cut and dried, in my view. I still have to go into frameworkd.conf every time I flash the phone and set the DSP to long-aec to avoid echo and sporadic audio clipping, as well as raising the volume in playback and mic in gsmhandset.state... and I'm still not satisfied with audio quality. So, can someone please humor David and me and explain this sidetone channel business? Thanks. Vasco. Citando Sebastian Krzyszkowiak seba.d...@gmail.com: On 8/7/09, Marcel tan...@googlemail.com wrote: Am Freitag, 7. August 2009 16:29:24 schrieb Sebastian Krzyszkowiak: On 8/7/09, David Fokkema dfokk...@ileos.nl wrote: - Why exactly are FR's different while I've never heard of Nokia users needing to tweak mixer settings. WTF? Every phone user tweaks mixer settings by using volume up and volume down buttons during call... In Freerunner we only miss good UI (from user point of view) and infrastrucuture behind it (from programmer point of view). Afaik, my Nokia 3510i doesn't even have such buttons and I never missed them... I'm pretty sure in Nokia 3510i up and down buttons control volume during call, as in Nokia 3310 and Nokia 3410. And most of users just set volume once, when they can't hear something or they think volume is too loud, and then they forgot about it - but it's still volume tweaking, and exactly the same is possible in Freerunner, just software is missing! -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Visit at Openmoko
Hey, take it easy, stop going berserk, and wait for the announcement. They will talk to us when they're good and ready, so save your energy for then, and stop raising confusion. Be civilised. Be smart. Be silent (until necessary). Citando Moko Mania mokom...@gmail.com: we are very much alive and well -- That's official. Thanks for caring is this MokoSarcasm? According to Whoiswho on the wiki almost everybody got laid off. Is the design team behind the layoffs? Are you part of the design team that took our raster already? If it's true then there is no more kernel support, no more software releases. How about customer support? Who is alive and well? The design team that cannot even design a simple functioning phone UI? Is your statement the only official statement we will hear for how long? Please don't tell me that everybody who ever did anything good for the community was fired. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Citando KaZeR ka...@altern.org: Indeed, stopping fso-gps made it work, thanks for the hint. The drawback is that you loose all the benefits of fso's gps handling : on demand statup, shared access, etc. That's more or less true. You see, when you stop the fso-gpsd, you only stop the gpsd compatibility layer daemon. The framework is still working. This means that if you connect to DBUS Gypsy service the framework will open the device again. fso-gpsd is just another client for the Gypsy service. However, if you are in fact reading directly from /dev/ttySAC1 and simultaneously try to read from Gypsy DBUS, the info probably will get mangled for both clients. Besides, I forgot to mention this: the framework talks binary UBX with the chip, so reading from /dev/ttySAC1 at the same time gives you UBX binary garbage, not NMEA ASCII text. So the current workaround that allows us to fully control the chip and have NMEA output is to stop fso-gpsd _and_ any other DBUS listener so that the framework releases the device; then we can power it off and on via /sys to reset the default config (NMEA mode) just in case; and then we can safely play around with cat and tail and /dev/ttySAC1. But as soon as any other app requests the Gypsy DBUS service, hell brakes loose. V. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Citando Ed Kapitein e...@kapitein.org: Does anyone know a program/script that converts the dbus messages to gpx format? Now i us gpspipe to get nmea and gpsbabel to create gpx files. Ideally, _someone_ should join the effort in FSO and expand fso-gpsd to produce GPX output... ;) (I'm presuming gpspipe is just a dumb socket listener). V. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Thanks for the hints, GUYS.
Yes, I usually do disable all the message types I don't need, leaving
only GPRMC and GPGGA. :)
I think I've found the bottleneck on this issue, and filed bug #431 on FSO.
http://trac.freesmartphone.org/ticket/431
Citando mqy meng.qing...@gmail.com:
read this: http://www.nabble.com/GPS-at-4-Hz-td17096809.html
NOTE about baud rate. If you can't change it, you can disable some NMEA
messages to make sure
the default baud rate (9600) is ok for 4hz rate.
On page 106, u-blox5_Protocol_Specifications(GPS.G5-X-07036).pdf says:
... The calculation of the navigation solution will always be aligned to
the top of a second.
Vasco Névoa wrote:
I've tried configuring (via frameworkd's om.py) the chip with a 3000ms
period between samples, and sure enough gpspipe is outputting only one
set of messages per every 3 seconds - so this proves my CFG-RATE
message is correctly delivered.
However, I also see that the gpspipe output is... chaotic. Although
the NMEA timestamps are always correct (they skip 3 seconds),
sometimes the messages are delayed and then delivered in batches. For
example, there is nothing for 6 seconds, and both messages are
delivered together.
If I set the period to 5.25 seconds, I can see that all the timestamps
coming out of gpspipe end with .00, which is obviously wrong.
Many of the sentences are repeated, like the SW couldn't wait for the
next UBX data block and just repeated the last data block.
Who is doing this sample mangling?
Citando Vasco Névoa vasco.ne...@sapo.pt:
Hi all.
I'm used to putting the GTA02's ublox chip into 4Hz sample mode for my
research projects, but ever since I started using FSO and derivatives
I can't get it to spit out anything other than 1Hz samples - so I just
stop fso-gpsd, configure the chip at my own will, and read directly
from /dev/ttySAC1.
However, this is the unfriendly way to do it, and I'd like to
integrate this option with FSO.
So I found the initialization sequence inside
/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/om.py
and added this to the end of def initializeDevice, just before the
self.huiTimeout = gobject.timeout_add_seconds( 300,
self.requestHuiTimer ):
# increase sample data rate to 4Hz:
self.send(CFG-RATE, 6, {Meas : 0x00fa, Nav : 0x0001,
Time : 0x})
Unfortunately, it doesn't change anything. gpspipe -r will still put
out a single set of messages per second, even though the GPS chip is
(hopefuly) configured for 4 sets per second. When used with the
original gpsd in other older distros, this didn't happen; gpspipe -r
outputs whatever the the gpsd delivers. So the problem is most likely
in FSO's ogpsd implementation.
Sending a u-blox binary string into /dev/ttySAC1 with the same config
message while fso-gpsd is working also doesn't work out (I've tried
many times just in case I'm racing with the framework and messages get
mangled).
I've combed the framework code in that folder trying to find any 1s
cycle hardcoded, but everything looks as it should: event-triggered by
available data.
So the 1M€ question is: where the heck is this 1s polling cycle
defined? How can I get the ogpsd framework to output 4 samples per
second instead of 1?
Any hints will be appreciated.
Thx,
V.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
--
View this message in context:
http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2886833.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
I don't have much of a problem there... see this: http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#Configuration_for_a_higher_sampling_rate However, you must remember that frameworkd sends a lot of configurations into the chip, and it keeps talking to it, so it might be a bit of a hassle to get the chip to listen to you without shutting down the framework. Usually, I just do /etc/init.d/fso-gpsd stop and avoid launching any GPS application. This makes sure the frameworkd shuts down the GPS chip and lays off it. Then I can send in UBX packets into /dev/ttySAC1 and tail -f /dev/ttySAC1 without problems. Citando KaZeR ka...@altern.org: Hello list, I also noticed last time i tried that i wasn't able to filter GPLL, GPGSA and friends using the ubxgen script from the wiki. Is it related? -- View this message in context: http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2888680.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Citando Helge Hafting helge.haft...@hist.no: Ouch. Having the framework _managing_ the gps (turn on/off, configure,...) is fine. But why regenerate the data, what is wrong with pass-through? The more cpu work, the more delays. And the gps may very well be used for real-time purposes. And of course, 100% of the cpu is not available, so it is hard to know how much extra work is too much. You could try uninstalling fso-gpsd, installing normal gpsd and somehow persuading frameworkd to not touch the gps (don't konw if setting the GPS to off is enough...) And the ideal fix would be framework support, so you just tell it you want 4HZ updates and from then on you get that. Helge, you're quite right, but gpspipe is a legacy application, and the preferred way is to sit on the DBUS interface for signals. I'm just using gpspipe because I already had a nice script to import data in NMEA format. ;) I suppose the FSO people will strongly suggest that users stick to the DBUS instead of consuming NMEA text, and that's what makes sense (even according to your own optimization rationale). So, asap, I'm going to code my app in python to use DBUS and avoid all this NMEA nonsense from the start. But the problem remains: ogpsd does not accept more than one position change per second and so I opened the ticket. http://trac.freesmartphone.org/ticket/431 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Hi all.
I'm used to putting the GTA02's ublox chip into 4Hz sample mode for my
research projects, but ever since I started using FSO and derivatives
I can't get it to spit out anything other than 1Hz samples - so I just
stop fso-gpsd, configure the chip at my own will, and read directly
from /dev/ttySAC1.
However, this is the unfriendly way to do it, and I'd like to
integrate this option with FSO.
So I found the initialization sequence inside
/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/om.py
and added this to the end of def initializeDevice, just before the
self.huiTimeout = gobject.timeout_add_seconds( 300,
self.requestHuiTimer ):
# increase sample data rate to 4Hz:
self.send(CFG-RATE, 6, {Meas : 0x00fa, Nav : 0x0001,
Time : 0x})
Unfortunately, it doesn't change anything. gpspipe -r will still put
out a single set of messages per second, even though the GPS chip is
(hopefuly) configured for 4 sets per second. When used with the
original gpsd in other older distros, this didn't happen; gpspipe -r
outputs whatever the the gpsd delivers. So the problem is most likely
in FSO's ogpsd implementation.
Sending a u-blox binary string into /dev/ttySAC1 with the same config
message while fso-gpsd is working also doesn't work out (I've tried
many times just in case I'm racing with the framework and messages get
mangled).
I've combed the framework code in that folder trying to find any 1s
cycle hardcoded, but everything looks as it should: event-triggered by
available data.
So the 1M€ question is: where the heck is this 1s polling cycle
defined? How can I get the ogpsd framework to output 4 samples per
second instead of 1?
Any hints will be appreciated.
Thx,
V.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
I've tried configuring (via frameworkd's om.py) the chip with a 3000ms
period between samples, and sure enough gpspipe is outputting only one
set of messages per every 3 seconds - so this proves my CFG-RATE
message is correctly delivered.
However, I also see that the gpspipe output is... chaotic. Although
the NMEA timestamps are always correct (they skip 3 seconds),
sometimes the messages are delayed and then delivered in batches. For
example, there is nothing for 6 seconds, and both messages are
delivered together.
If I set the period to 5.25 seconds, I can see that all the timestamps
coming out of gpspipe end with .00, which is obviously wrong.
Many of the sentences are repeated, like the SW couldn't wait for the
next UBX data block and just repeated the last data block.
Who is doing this sample mangling?
Citando Vasco Névoa vasco.ne...@sapo.pt:
Hi all.
I'm used to putting the GTA02's ublox chip into 4Hz sample mode for my
research projects, but ever since I started using FSO and derivatives
I can't get it to spit out anything other than 1Hz samples - so I just
stop fso-gpsd, configure the chip at my own will, and read directly
from /dev/ttySAC1.
However, this is the unfriendly way to do it, and I'd like to
integrate this option with FSO.
So I found the initialization sequence inside
/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/om.py
and added this to the end of def initializeDevice, just before the
self.huiTimeout = gobject.timeout_add_seconds( 300,
self.requestHuiTimer ):
# increase sample data rate to 4Hz:
self.send(CFG-RATE, 6, {Meas : 0x00fa, Nav : 0x0001,
Time : 0x})
Unfortunately, it doesn't change anything. gpspipe -r will still put
out a single set of messages per second, even though the GPS chip is
(hopefuly) configured for 4 sets per second. When used with the
original gpsd in other older distros, this didn't happen; gpspipe -r
outputs whatever the the gpsd delivers. So the problem is most likely
in FSO's ogpsd implementation.
Sending a u-blox binary string into /dev/ttySAC1 with the same config
message while fso-gpsd is working also doesn't work out (I've tried
many times just in case I'm racing with the framework and messages get
mangled).
I've combed the framework code in that folder trying to find any 1s
cycle hardcoded, but everything looks as it should: event-triggered by
available data.
So the 1M€ question is: where the heck is this 1s polling cycle
defined? How can I get the ogpsd framework to output 4 samples per
second instead of 1?
Any hints will be appreciated.
Thx,
V.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] kernel with working g_ether to Windoze connection?
Thanks, Paul. I ended up upgrading from shr-testing to shr-unstable, and the problems are gone. So, the non-functional kernel+g_ether must have been: http://shr.bearstech.com/shr-testing/images/om-gta02/uImage-2.6.28-stable+gitr0e5fe639e234cdeb11d8441f19c5b3109a8b6a17-r2-om-gta02.bin And the current working one is: http://shr.bearstech.com/shr-unstable/images/om-gta02/uImage-2.6.29-oe10+gitr119805+f656a97d946a2529630c9770a72c10a24dc397f9-r3.4-om-gta02.bin I was just surprised to see the problem getting fixed and lost and refixed at least 2 times in a row. It feels like someone made a patch and it just doesn't stick - maybe it didn't make it upstream and sometimes it isn't appllied? I don't know the kernel source stream from vanilla down to SHR, so I'm talking out of my... imagination. ;) Anyway, I'm glad it is solved, and I hope it doesn't come back so easily again. Citando Paul Fertser fercer...@gmail.com: Vasco Nevoa vasco.ne...@sapo.pt writes: Why don't you just specify which kernel revision works and which doesn't? How any kernel dev is supposed to solve your problems if you even don't properly describe it? Why don't you use the kernel that worked on your FR in the meantime? If I knew, I wouldn't have a problem, would I? :) At least you know the date (and the place you downloaded) the kernel had no problems and the problematic revision you use now, but you don't specify it. The kernel commit that finally fixed RNDIS issues was f63e59c84aa21d2745f115209bf949eca27008b1 and it was added to andy-tracking branch on Mar 16. I don't see anything related since then. Since you don't specify what revision you use now, i'm unable to even say if your rev includes the commit or not. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[shr-testing] kernel with working g_ether to Windoze connection?
Hi folks. The opkg upgrade broke the USB connectivity to Windows boxes once again. Can anyone tell me which kernel versions have this running? Thx. V. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] kernel with working g_ether to Windoze connection?
I would, but I don't think my employer would agree. :) I use nothing but FLOSS everywhere, except of course at work, where I have to use the official workstation software... :P And it is very handy to hack the latest tweaks on my neo while waiting for a compilation to finish... ;) Right now, the Neo is networkless with SHR-testing in a Windows environment: - wifi is no good; - bluetooth way too complicated; - USB doesn't work; - GPRS stalls and doesn't allow opkg update, so forget upgrade SO GIMME THE WORKIN KERNEL ALREADY!!! :D I just find it strange all this back and forth, one version it works, the next it doesn't, then it works again, then not is that patch so difficult to keep alive?? Citando jeremy jozwik jerjoz.for...@gmail.com: switch to linux! or do a dual boot. i dont know how anyone could manage to do anything with an openmoko without some kind of linux box. plus its free : ) 2009/5/6 Vasco Névoa vasco.ne...@sapo.pt: Hi folks. The opkg upgrade broke the USB connectivity to Windows boxes once again. Can anyone tell me which kernel versions have this running? Thx. V. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-testing 2009-05-02 broken?
I had to reflash because DBUS wasn't running the way it should and so all the phone apps were broken. :( But now the new kernel broke the windows USB connectivity again!!! Aaarrgghh!! Citando Robin Paulson robin.paul...@gmail.com: 2009/5/4 Vasco Névoa vasco.ne...@sapo.pt: That's not all that broke. I opkg upgraded today, and shr-testing wouldn't launch X11 after a reboot. It is looking for a bunch of modules named /usr/lib/evas/modules/*/*/linux-gnueabi-arm-ver-pre-01/module.so, but the only ones that exist are /usr/lib/evas/modules/*/*/linux-gnueabi-arm/module.so So I linked the directories that do exist with the names that it is looking for, and it is working again. Why is X11 looking for linux-gnueabi-arm-ver-pre-01 instead of linux-gnueabi-arm, and why doesn't my system have it? someone upstream changed the name of the e packages, and opkg update + opkg upgrade is now broken. apparently the only way to get the new shr-testing is to re-flash, or do what you've done or wait till it's fixed by shr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-testing 2009-05-02 broken?
That's not all that broke. I opkg upgraded today, and shr-testing wouldn't launch X11 after a reboot. It is looking for a bunch of modules named /usr/lib/evas/modules/*/*/linux-gnueabi-arm-ver-pre-01/module.so, but the only ones that exist are /usr/lib/evas/modules/*/*/linux-gnueabi-arm/module.so So I linked the directories that do exist with the names that it is looking for, and it is working again. Why is X11 looking for linux-gnueabi-arm-ver-pre-01 instead of linux-gnueabi-arm, and why doesn't my system have it? Citando Angus Ainslie nyt...@openmoko.org: On Mon, 2009-05-04 at 17:11 +0300, Yogiz wrote: Thank you both for the information. I'll use this chance to check out the new Openmoko 2009 testing image and I'll return to SHR once the problem gets sorted out. Om2009 has the same problem as the issue is with e upstream. We are also waiting/looking at a fix. Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-unstable]Blinking AUX button LED
Possible errors that lead to that situation: - bad rootfs kernel parameters in u-boot environment; - check if you need to change them; - missing kernel modules for the specific filesystem you have formatted; - either mismatch between rootfs and kernel images, or just plain bad kernel image; - corrupt root filesystem, flash it again - pay CLOSE attention to the dfu-util parameters if you are new to this. Good luck!... :) Citando Davide Scaini dsca...@gmail.com: uhm... ... ... I can't give you an answer 'cause I get a kernel panic... and i can't connect to the fr... ;-) d On Thu, Apr 30, 2009 at 11:04 AM, Timo Juhani Lindfors timo.lindf...@iki.fi[1] wrote: Davide Scaini dsca...@gmail.com[2] writes: i do not boot at all... but the message is Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,6) Your kernel lacks mtdblock support then? (ls -l mtdblock6 shows 31, 6) ___ Openmoko community mailing list commun...@lists.openmoko.org[3] http://lists.openmoko.org/mailman/listinfo/community Ligações: - [1] mailto:timo.lindf...@iki.fi [2] mailto:dsca...@gmail.com [3] mailto:community@lists.openmoko.org___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] 4-16 shr-testing is pretty good!
That explains it. :) Well, Xavier, I gave up on my Portuguese accentuated characters a while ago. Since I only use the keyboard's dictionary for SMS messages, it's ok (kids today are writing a lot worse on SMS than just a few missing accents...) ;) It would be good to have someday, but I won't bother opening a ticket when there is much bigger fish to fry first. Citando Paul Fertser fercer...@gmail.com: Xavier Cremaschi omega.xav...@gmail.com writes: Vasco Nevoa a écrit : And Raster's keyboard finally works the way it should (fast and clean). With utf-8 support or not ? If I wrote 'ete' with my french dictionary, will it propose me 'été' ? Because IIRC, it was an utf-8 patch that made it very slow in the old SHR-testing... Without, the patch was reverted. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to fix missing icons in SHR-Unstable
Removing e-wm-utils and installing it again, plus your file, worked for me (after today's update). Thanks all! :D Citando The Digital Pioneer digitalpion...@gmail.com: Ahh, so I guess I halfway fixed it without noticing... OK, so reinstall e-wm-utils and then fix applications.menu? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Detecting ethernet gadget connections
I opened a ticket on that a while ago... https://docs.openmoko.org/trac/ticket/2178 No progress in 3 months... Citando Daniel Benoy dan...@benoy.name: I'm working on a script that will detect which network interfaces are connected and mess with the routing accordingly, but I'm having trouble detecting whether my USB ethernet gadget connection is up or down. ethtool when it's up: lisa:~# ethtool usb0 Settings for usb0: Link detected: yes ethtool when it's down: lisa:~# ethtool usb0 Settings for usb0: Link detected: yes Unlike on the host side, the usb0 interface doesn't appear and disappear, allowing udev scripts to bring up/down the interface. Anyone know if there's a way to detect that a network connection has actually been established? -- Daniel Benoy http://daniel.benoy.name ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR unstable] no USB networking (with Windows)?
Thanks Paul, that's exactly it. So, it's most probably a 2.6.* USB driver problem and we'll have to wait for the kernel folks to get it right... Citando Paul Fertser fercer...@gmail.com: Vasco Névoa vasco.ne...@sapo.pt writes: Second, a weird problem I'm having... I updated my system with opkg yesterday, and a bunch os problems were corrected (yay!) and I'm using the phone in everyday life, but now I can't login via SSH on my windows box. http://docs.openmoko.org/trac/ticket//2211 -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR unstable] no USB networking (with Windows)?
There is also a closed ticket for the same bug (with different symptoms, but that should be a Windows problem I guess): http://docs.openmoko.org/trac/ticket/1279 It looks like this patch is going in and out, or something... the problem comes and goes depending on kernel version... Citando Paul Fertser fercer...@gmail.com: Vasco Névoa vasco.ne...@sapo.pt writes: Second, a weird problem I'm having... I updated my system with opkg yesterday, and a bunch os problems were corrected (yay!) and I'm using the phone in everyday life, but now I can't login via SSH on my windows box. http://docs.openmoko.org/trac/ticket//2211 -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR unstable] no USB networking (with Windows)?
Hi folks. First off, a BIG THANKS to the SHR team; this is the best distro I tried for GTA02 in a long while. :) Second, a weird problem I'm having... I updated my system with opkg yesterday, and a bunch os problems were corrected (yay!) and I'm using the phone in everyday life, but now I can't login via SSH on my windows box. This works just fine if I reboot into the Hackable:1 distro on the card and also worked fine with the OM2008.12/testing distro previously on flash. The g_ether module is loaded and the usb0 interface is UP and configured with the correct IP... but the Windows box just doesn't connect anymore. I don't have a Linux box here, I'll have to try much later on. Hints, anyone? Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
password vault?
Hi all. Does anyone know a good password vault application that we can use in OM? Thanks, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: password vault?
Thanks Rainer Angus!! :) Citando Fox Mulder quakem...@gmx.net: I'm useing KeepassX [1] which is opensource and available for windows, linux, handy java j2me, on usb-sticks and many more. The database is aes encrypted and is compatible between all these keepass versions. It is available in the openmoko debian repo. Ciao, Rainer [1] http://www.keepassx.org/ Angus Ainslie wrote: Try Pyring it's on opkg.org On Jan 9, 2009, at 7:24 AM, Vasco Névoa vasco.ne...@sapo.pt wrote: Hi all. Does anyone know a good password vault application that we can use in OM? Thanks, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Car Charger?
Citando Rui Miguel Silva Seabra r...@1407.org: Shouldn't it have to be 2A ? Why should it? If the FR can charge at 3 different rates (100, 500, 1000mA), any charger that can give 500 or 1000mA is good enough... it all depends on how much time you want to wait for a charge... ;) I tested it right now, and it does charge. The problem is that this Trust car cigarette lighter USB charger does not have the ID pin resistor [1]. Even when using a standard USB-to-miniUSB cable the FR recognizes the charger as a 100mA host port (and charges at 100mA, which is not good enough). So I used the sysfs entries in [2] to force it to 500mA and 1000mA and all went well - it can charge just fine, but has to be forced because there is no auto detection. So now I just install the usb charging control scripts in [2]... :) [1] http://wiki.openmoko.org/wiki/USB_charger [2] http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode Happy hacking! Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Car Charger?
Well... not exactly. I bought a Trust car lighter adapter (5V/1A) with its own cable, and it doesn't charge the freerunner. After reading all this, I think it must be the cable. I'm going to try with a standard cable instead of the supplied one. The supplied cable is very handy, it has all kinds of optional plugs for many kinds of phone and gadget; because of this, it has only power lines going through it, and no data lines at all (it's got a small plug with only 2 contacts where the other adapter plugs connect). I'll let you know... Citando Gothnet openm...@nastylittlehorse.net: Thanks for all the answers guys, looks like I can grab any old USB charger, 5V/2A being preferable. And a GPS style wndscreen mount would be useful. I'm sure I can find something though. -- View this message in context: http://n2.nabble.com/Car-Charger--tp2106770p2112932.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gsm0710muxd and OM 2008.12
I had a few problems with that myself, but they ended when I simply
removed all gsm0710muxd links from /etc/rc*.d/.
I think it gets launched on demand when you call it via dbus... and so
the 89qtopia line does the trick.
If you let it launch via 2 different ways at the same time, there
seems to be a race for modem control and QPE ends up loosing the battle.
This is working for me.
Citando Ed Kapitein e...@kapitein.org:
Hi Jan,
I had the same problem and found an even dirtier sollution ;-)
I found that sometimes gsm0710muxd will give an /dev/pts/X but you can
not use it, there is no response from the modem.
And sometimes even stopping gsm0710muxd and starting it again would not
help.
so in order to have it working all the time i modified
/etc/X11/Xsession.d/89qtopia
just below
export QTOPIA_PHONE_MUX=ficgta01
i added:
#---
echo 0 /sys/devices/platform/neo1973-pm-gsm.0/power_on
sleep 2
/etc/init.d/gsm0710muxd stop
sleep 2
killall -9 gsm0710muxd
sleep 2
echo 1 /sys/devices/platform/neo1973-pm-gsm.0/power_on
sleep 2
/etc/init.d/gsm0710muxd start
sleep 2
identvar=$(date +%s)
ptsvar=$(dbus-send --system --print-reply --type=method_call
--dest=org.pyneo.muxer /org/pyneo/Muxer
org.freesmartphone.GSM.MUX.AllocChannel string:$identvar | grep string |
awk -F '' '{ print $2 }')
export QTOPIA_PHONE_DEVICE=$ptsvar
echo $QTOPIA_PHONE_DEVICE
#---
(the ptsvar line is one long line, it might be chopped up in the mail)
In my opinion, this will reset the modem no matter what.
and i removed gsm0710muxd from all run levels
( update-rc.d -f gsm0710muxd remove )
I am using stock 2008.12, nothing from another repro.
So far this is working flawlessly for me.
Inspired by the [FSO/SHR/debian] SMS location app, i wrote some scripts
to check for an incomming SMS and send me the GPS location of my FR.
So i needed the gsm0710muxd to read the SMS, while still being able to
use the phone.
Kind regards,
Ed
On Mon, 2008-12-29 at 14:07 +, Jan Henkins wrote:
Hello Eldon and Olivier,
Eldon, I've been scratching my head on this very same issue.
On Sun, December 28, 2008 08:31, Olivier Berger wrote:
Eldon Koyle eko...@gmail.com writes:
I just spent a while tracking down an issue with 2008.12 and
gsm0710muxd. I upgraded an FDOM image, so I'm not sure if anyone else
will see this problem, but just in case I thought I'd send this to the
list.
2008.12 was starting xserver-nodm before gsm0710muxd, so the dbus call
added in /etc/X11/Xsession.d/89qtopia started a separate gsm0710muxd
process without any args before gsm0710muxd was started by init which
caused gsm0710muxd to fail to work.
A quick fix is to change xserver-nodm from S04 to S23 (gsm0710muxd is
22) or so in /etc/rc5.d .
Hmm, a dirty fix, but something I will try out. I will let you know if it
succeeded. BTW, I'm using the stock 2008.12 image with Illume (ASU *very*
broken...).
Well... and would you mind to share with us the problem you're trying
to solve ? It's far from obvious what this gsm0710muxd may be doing,
and how it's missing ;)
Olivier, it would seem to me that the issue is the following:
xserver-nodm starts up before gsm0710muxd. The problem comes in that qpe
needs to connect to a device, which is supposed to be created by
gsm0710muxd. This is neccessary in order to multiplex gsm and gprs,
otherwise you have an either/or situation (better to have both voice and
gprs, at least it is for me! ;-) Now, qpe complains that it cannot find
the device as configured in the 89qtopia file, and then dies. This is true
even if you launch qpe with app-restarter like this:
/usr/bin/app-restarter $QTOPIA_MESSAGE qpe 21 | logger
Doing a dirty fix like Eldon suggested *might* help, I will try and
confirm this on my FR.
Btw, did you file a ticket in the bug tracker ?
It seems to be a bit more complicated than simply filing a ticket, since
it is a strange situation to debug. To compound the issue, it would also
seem that gsm0710muxd might be the faulty link in the chain, since I could
not get it to work properly. Furthermore, I've been reading about random
hassles with gsm0710muxd on a few blogs here a there, where it is
reccommended to use the gsm0710muxd from the Angstrom repo instead of the
2008.x version. I found this to be a dicey route to follow, since
everything in Angstrom is newer than 2008.12, and you will end up having
to update just about the entire base due to dependencies. Ouch...
Maybe somebody else have experienced the same issue with gsm0710muxd in
2008.12? Please let us know. If we can get parity on actual version
numbers and replicate the problem between two or more people, we can then
file a bug with some proper debugging material for the OM guys to sink
their teeth into.
Speaking for myself, I would like to get this issue resolved
Re: New 2008.12 Release
That's strange, I didn't get the announce mail... Citando Rui Miguel Silva Seabra r...@1407.org: On Fri, Dec 19, 2008 at 12:25:19PM +0200, Yogiz wrote: Good news. I'll still wait for the announcement and for some feedback before I roll it on. I've spent too much time customizing my 2008.9 to mess with it. I've received the official announcement around 30 minutes ago. In this list or where? Could someone point out the biggest changes? OpenMoko announce list. http://lists.openmoko.org/pipermail/announce/2008-December/28.html Rui -- P'tang! Today is Pungenday, the 61st day of The Aftermath in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: New 2008.12 Release
Citando KaZeR ka...@altern.org: Pro : - OMG fast boot time (press power for 8 seconds (boring, why so long?), start stopwatch at first line of text. Time to desktop : 38s! Strange, I have an OM2008.9 fully updated with testing and my bootup time is 30 seconds more than that... anyone can explain this? - Phone goes to suspend even if you have usb connected. So, you loose the network connection. But that has always been like that, right? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Answer from Joerg (was: Re: Crackly Calls and Battery Tips! A5/A6 rework. Corrected URL)
I did the big-c buzzing rework myself, with the precious help of a much more smd-experienced colleague. It was very difficult to replace the resistor because of the proximity of the components around the mic. A very sharp soldering iron is critical. I used a 1k resistor (didn't have a 2k2 of the same size at hand), and a 100uF/10V tantalum capacitor. So far, so good! The buzz seems to be gone for good. :) One caller has reported that I sounded like at the bottom of a pit, but this can be the other older issue... Citando Paul Fertser fercer...@gmail.com: Joel Newkirk freerun...@newkirk.us writes: Still waiting for an answer from OM. (I posted a question in this thread Friday regarding Tanatalum instead of Ceramic cap - the difference being $0.25 vs $2 each in qty 100, and my radio guy thinks Tant is a good choice for filtering, but waiting for word from Steve or Jeorg) Joel, Joerg overlooked your question on the community mailing list, you should have asked at hardware list instead. I asked him on IRC: here's the answer: 12:57 PaulFertser DocScrutinizer: could you please answer a question wrt capacitor type for the gsm buzz fix? Joel Newkirk asks whether he can use tantalum instead of ceramic ones as tantalum are much cheaper and he's going to perform a rework on a reasonable quantity of units (IIRC). 13:00 DocScrutinizer PaulFertser: we don't have any tantalum caps here, and I would guess they are just too big. I was about to suggest a free caeramic cap for everyone asking for it. actually I'll bring a handfull of those to Germany on Sunday 13:00 DocScrutinizer PaulFertser: technically there is nothing wrong with tantalum 13:01 DocScrutinizer though I'd guess they are somewhat harder to solder, as they're basically electrolytic caps and so won't stand much heat 13:01 PaulFertser DocScrutinizer: if you don't mind, i'm going to post your answer on the community mailing list in the corresponding thread. 13:02 DocScrutinizer go ahead, you're welcome 13:02 DocScrutinizer just quote this dialog is fine 13:04 DocScrutinizer also, to whom it may concern, I plan to join 25C3 congress in Berlin, and maybe rework a couple of devices there for free, or at very least give away caps -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[OM2008] USB events - scripts?
Hi all. I want to run a script automatically every time the USB is plugged or unplugged. Where should I hook in the scripts? /etc/apm/?/... or somewhere else? I've looked into using the /etc/network/interfaces, but this doesn't work because usb0 does not get downed on unplug - so it is always up since booting... Thanks, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Android] Converting a brick into a phone
I'm kinda confused here... is this buzz issue the one where the caller (not the neo) hears the GSM buzzing? The one that has a SOP repair paper with the Big C?... or is it something else? Citando Michel [EMAIL PROTECTED]: Steve Mosher wrote: Hi Steve, A list on the wiki of all severe problems and the end user details would be great, especially for future reference. Some of the problems, like Buzz, 1024 (recamp) seem to happen to some people and not others. I never had the buzz problem, go figure. I've created the page. 1. problems: WSOD, recamp, Buzz, echo ( insert gripe) 2. End user data: a. email (optional) b. Date code on phone ( under battery) c. s/n d. p/n e carrier. f. 900Mhz or 850? g distro etc... The page links from http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware_Issues#Poor_Audio_Quality And you can find it here: http://wiki.openmoko.org/wiki/Buzz_or_not Please ad fields if necessary anything else? It might be nice to know what band the phone is operating on ( 900/1800/1900) if that's possible. Tell me how I can find that info on the phone :) Steve Regards, Michel -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Crackly Calls and Battery Tips! A5/A6 rework. Corrected URL
I'd really like pictures with better focus and a little more light... especially the last one, which is very blurred! Citando Steve Mosher [EMAIL PROTECTED]: Sorry, I pulled the old copy. See below SOP paper (draft3, 2008-12-10 19:00) placed here: http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP__DRAFT3__.pdf Please have a look and report on any mistakes or things that need improvement. Thanks jOERG Neil Jerram wrote: 2008/12/10 Steve Mosher [EMAIL PROTECTED]: The DRAFT fix for the buzz problem is here: CP of joerg's mail. http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP__DRAFT!!__.pdf I'm getting 404 for this URL. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[OM2008.8][testing] qpe no longer respects QTOPIA_PHONE_DEVICE ?
After today's testing upgrade, QPE is ignoring env var QTOPIA_PHONE_DEVICE and going right for /dev/ttySAC0 instead of a /dev/pts* like I want it to. What is the new way to make it pick another device? Surely you devs haven't forgotten there are people using gsm0710muxd?... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.8][testing] qpe no longer respects QTOPIA_PHONE_DEVICE ?
There is no problem with QPE and the QTOPIA_PHONE_DEVICE var. The problem is that gsm0710muxd gets started twice (via rc.d init scripts AND the dbus request inside 89qtopia) and QPE gets a bogus ptsvar and falls back to /dev/ttySAC0. I removed the rc.d startup of the muxer because dbus is capable of launching it upon request: update-rc.d -f gsm0710muxd remove And it all works (GSM+GPRS)! :) Citando William Kenworthy [EMAIL PROTECTED]: I'm also noticing today that the batget utility is blocking (using top), sometimes several instances get caught up and the phone starts to slow. removed the battery module (its utterly useless in illume anyway) and things run much better. Overall though, there are fewer problems than 2008.9 :) BillK On Fri, 2008-12-05 at 11:42 +, Vasco Névoa wrote: After today's testing upgrade, QPE is ignoring env var QTOPIA_PHONE_DEVICE and going right for /dev/ttySAC0 instead of a /dev/pts* like I want it to. What is the new way to make it pick another device? Surely you devs haven't forgotten there are people using gsm0710muxd?... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- William Kenworthy [EMAIL PROTECTED] Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
Yes, that's how I get my ballance... it's the operator that automatically sends it at hangup. I confirm that the dialer exits when we try to do it upon request... Citando Marco Trevisan (Treviño) [EMAIL PROTECTED]: Vadim, Efimov wrote: Another 2 positive points I forgot to mention: - the UCSD messages are now correctly displayed (yay, I can see my account balance!!) how? i call *102# and dialer just disappear... I figure that actually only the ones sent by operator (with no an explicit request, i.e. after a call) are working. There's an issue while placing an USSD request... -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
I also went that way and hacked the qwerty button in again (but not
the wrench - didn't know how).
However, the button is there and it reacts, but the keyboard does not appear.
Instead, it controls the appearance of the qtopia keyboard...
How do we reach the illume keyboard from this button?
Citando John Lee [EMAIL PROTECTED]:
On Wed, Dec 03, 2008 at 08:36:53AM -0800, Martin Benz wrote:
Read the bugreport:
https://docs.openmoko.org/trac/ticket/1767
So we have a slow illume-theme with rasters keyboard or a fast asu-theme
without an usable keyboard (especially for non-engish users)...
Maybe i'll try to hack the edj-file, did manage to get the qwerty-menu back
in the wrench, but messing around with the keyboard only gave me errors when
running build.sh...
(See Method 2 from http://wiki.openmoko.org/wiki/Keyboard_Toggle)
cheers
Martin
actually it's quite easy to bring back the wrench and the qwerty
buttons in asu theme. it's not the real issue though.
wrench: it's a gadget to put on the illume 'shelf'. so just add it
back into the config then it will show up. something like this
(haven't tested):
Index: illume-theme-asu/config/e.src
===
--- illume-theme-asu/config/e.src (revision 4796)
+++ illume-theme-asu/config/e.src (working copy)
@@ -428,6 +428,24 @@
value resizable uchar: 0;
}
}
+ group clients list {
+group E_Config_Gadcon_Client struct {
+ value name string: configuration;
+ value id string: configuration;
+ value geom.pos int: 0;
+ value geom.size int: 32;
+ value geom.res int: 472;
+ value geom.pos_x double: 0.0;
+ value geom.pos_y double: 0.0;
+ value geom.size_w double: 0.0;
+ value geom.size_h double: 0.0;
+ value state_info.seq int: 1;
+ value state_info.flags int: 1;
+ value style string: plain;
+ value autoscroll uchar: 0;
+ value resizable uchar: 0;
+}
+ }
}
}
value font_hinting int: 0;
qwerty: enable it in the theme.
Index: illume-theme-asu/misc-data/asu/freerunner.edc
===
--- illume-theme-asu/misc-data/asu/freerunner.edc (revision 4796)
+++ illume-theme-asu/misc-data/asu/freerunner.edc (working copy)
@@ -1575,8 +1575,8 @@
type: RECT;
mouse_events: 1;
description { state: default 0.0;
-// visible: 1;
-visible: 0; // sean wants it gone. don't look at me.
+visible: 1;
+// visible: 0; // sean wants it gone. don't look at me.
color: 0 0 0 0;
rel1 {
to_y: e.swallow.content;
@@ -1585,8 +1585,8 @@
rel2 {
to_x: kbdtext;
to_y: e.swallow.content;
-// relative: 1.0 1.0;
- relative: 0.0 1.0; // sean wants it gone. don't look at me.
+ relative: 1.0 1.0;
+// relative: 0.0 1.0; // sean wants it gone. don't look at me.
offset: -1 -1;
}
}
@@ -1595,8 +1595,8 @@
type: TEXT;
mouse_events: 0;
description { state: default 0.0;
-// visible: 1;
-visible: 0; // sean wants it gone. don't look at me.
+visible: 1;
+// visible: 0; // sean wants it gone. don't look at me.
align: 0.0 1.0;
fixed: 1 1;
rel1 {
the real problem is, after you click on the wrench, it will show the
config menu, but click on any one of them will give you black screen.
probably black fonts on black background. I hope someone can find out
what went wrong because I don't have time to work on it.
- John
Vasco Névoa wrote:
I've been trying the illume (gray) theme with the testing image, and
it is badly broken - Enlightenment keeps crashing at random moments
for reasons unknown.
I gave up on trying to have illume's keyboard, and reverted to the
original asu (black) theme. The qtopian keyboard sucks, but at least
everything else rocks.
I find it very strange that the whole image works so solidly with the
asu theme and is so flakey with the illume theme...
Citando Vasco Névoa [EMAIL PROTECTED]:
Citando William Kenworthy [EMAIL PROTECTED]:
And also yes, I have modified 89qtopia - but it doesn't seem to have
much of an effect :(
I found out how my illume keyboard went missing. From the wiki:
edit '/etc/enlightenment/default_profile' to use illume theme
instead of 'asu'
So, if you just want to get rid of it, replace illume with asu inside
/etc/enlightenment/default_profile ...
But if you want to keep
[OM2008.x] praise for the new testing image
I've followed the community update tip and upgraded from OM2008.8 stable to testing. After a little havoc caused by the previously installed gsm0710muxd, I finally got it to work on the GTA02v5. I've only had it for a day now, but already I am very pleased with the results! Reduced boot time, volume control during calls, and apparently a very well optimized energy consumption (still evaluating that). Jolly good show, lads!! :D Keep hacking that kernel, you're definitely in the right track now. ;) I can't wait for WiFi to get on track... :) My only gripe is the absence of Raster's keyboard, that I haven't been able to recover after the update... what's the magic there? Happy Hacking, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
Citando Tony Berth [EMAIL PROTECTED]: didn't you get WSOD? No, I never got it, with this image or with any other. I suppose it is HW-related?... probably one of those HW tolerances that is triggered by bad SW habits... :( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
Citando William Kenworthy [EMAIL PROTECTED]: Can you confirm that you can receive an SMS after being *suspended* for ~10 minutes or so? For me the phone comes out of suspend, but I have to reboot (or restart X) to get at the message, and twice the phone (not X) crashed after I accessed a message. Looking for confirmation I am not the only one seeing this with the update ... No problem so far over here, sorry!... I just got a couple of messages a few minutes ago, and it was definitely sleeping... Make sure your home files (if they are on card) that are acessed by QPE are not a problem. Search in logread for any binary compatibility qtopia problems; I remember there are some registry files that qtopia keeps that maybe out of synch with the real libs installed... Something that happened to me was that QPE was exiting because some file-indexing thread was dying... it works fine now that I disabled sd-card (home) indexing in /opt/Qtopia/etc/default/Trolltech/Storage.conf. I got rasters keyboard - in fact I cant get rid of the bloody thing! - I would like to just have terminal and none of the others as they keep changing back and forward halfway through typing messages :) You're right, it is a PITA. Do you have QTOPIA_NO_VIRTUAL_KEYBOARD=1 inside /etc/X11/Xsession.d/89qtopia ? Happy Hacking! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
Another 2 positive points I forgot to mention: - the UCSD messages are now correctly displayed (yay, I can see my account balance!!) - the illume resume bug (on first tap) is finally gone! (yay, no more danger of running out of battery during the night if an SMS or call comes in). Citando Vasco Névoa [EMAIL PROTECTED]: I've followed the community update tip and upgraded from OM2008.8 stable to testing. After a little havoc caused by the previously installed gsm0710muxd, I finally got it to work on the GTA02v5. I've only had it for a day now, but already I am very pleased with the results! Reduced boot time, volume control during calls, and apparently a very well optimized energy consumption (still evaluating that). Jolly good show, lads!! :D Keep hacking that kernel, you're definitely in the right track now. ;) I can't wait for WiFi to get on track... :) My only gripe is the absence of Raster's keyboard, that I haven't been able to recover after the update... what's the magic there? Happy Hacking, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
Citando William Kenworthy [EMAIL PROTECTED]: And also yes, I have modified 89qtopia - but it doesn't seem to have much of an effect :( I found out how my illume keyboard went missing. From the wiki: edit '/etc/enlightenment/default_profile' to use illume theme instead of 'asu' So, if you just want to get rid of it, replace illume with asu inside /etc/enlightenment/default_profile ... But if you want to keep it exclusively for the terminal, I don't know how... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
I've been trying the illume (gray) theme with the testing image, and it is badly broken - Enlightenment keeps crashing at random moments for reasons unknown. I gave up on trying to have illume's keyboard, and reverted to the original asu (black) theme. The qtopian keyboard sucks, but at least everything else rocks. I find it very strange that the whole image works so solidly with the asu theme and is so flakey with the illume theme... Citando Vasco Névoa [EMAIL PROTECTED]: Citando William Kenworthy [EMAIL PROTECTED]: And also yes, I have modified 89qtopia - but it doesn't seem to have much of an effect :( I found out how my illume keyboard went missing. From the wiki: edit '/etc/enlightenment/default_profile' to use illume theme instead of 'asu' So, if you just want to get rid of it, replace illume with asu inside /etc/enlightenment/default_profile ... But if you want to keep it exclusively for the terminal, I don't know how... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Raster keyboard on daily testing
See: http://wiki.openmoko.org/wiki/Keyboard_Debate#How_to_install_the_illume_.28Raster.27s.29_keyboard_.3F Beware: at least on my system, when I replace the base asu theme with the illume theme, Enlightenment crashes a lot. Citando Armin ranjbar [EMAIL PROTECTED]: How to get raster keyboard working on daily testing images ? -- Armin ranjbar , System Administrator ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] gsmspeakerout.state
I really don't like the fact that the state files have ALL the controls in there. Can't we eliminate the unnecessary controls inside each file? I don't see why a speakerout.state file should have microphone settings... it just adds to the confusion, and creates competition between apps. Citando Alastair Johnson [EMAIL PROTECTED]: Matthias Apitz wrote: El día Wednesday, November 19, 2008 a las 08:46:27AM +0530, Carl Lobo escribió: I think you need to restore the gsm*.state files only when you are on call. the ringing from speaker requires mappings from stereoout.state. Ok, I think that without deeper knowledge about the files I'm lost. Can some kindly soul sheet a bit light into this darkness? I.e. - Why there are different files? Because depending on what you are doing you want to send sound to different places, and with different levels. It is simpler to have a small set of files containing the mixer states for known situations than it is for every app to store all the mixer settings itself. - Which process is reading them, in which order and when? Anything that wants to, whenever it wants to, more or less. Essentially if an app wants to use a particular mixer state then it makes a call to set the mixer to that state. FSO has a dbus API to make this a little more orderly, and qtopia may have something similar, but this doesn't prevent an app setting things directly. Because it is up to the app to do the setting you may find that an app doesn't switch to the state you want, for example when you answer a call the phone app may switch to the gsm-handset state even though you have the headset plugged in. The Wiki http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem speaks about 'states' like 'State: GSM - Built-in Handset (file gsmhandset.state)', but does not explain what a given 'state' is and how the transit between them happens... Thx matthias ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New home for the New FDOM
I've also tried FDOMizer yesterday, and I had to patch it by hand in a few cases. Mainly, I had to update a few download links from angstrom-distribution.org . Citando Jonathan Schultz [EMAIL PROTECTED]: I just tried updating my FDOM using FDOMizer from the 20080927 version and have had some gains but a few losses and problems. Some of the applications work but others (notably GnuChess and Openmoocow) don't. In particular GnuChess just goes and consumes all available CPU without apparently doing anything. OpenMooCow doesn't appear to do anything either but at least doesn't take any CPU time. I'm guessing here but I'd think that all those forced dependencies are likely to be causing problems. For example I only have gtk+ v 2.10.14-r2 instead of 2.12.11; libglib-2.0.0 v 2.6.16.1-r4 instead of 2.16.4; libcairo2 v 1.4.10-r0 instead of 1.6.4. Should I be using a different repository here? There were a couple of files that the script attempted to download from angsgtrom that weren't available. Curiously enough the files that are available are older versions than those requested by the script. These are: http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libpurple-protocol-msn_2.5.1-r0.1_armv4t.ipk http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libpurple-libjabber_2.5.0-r0_armv4t.ipk There was something funny about the rc.local file, which the script update-rc.d expected to find in /etc/init.d but which were in /etc I copied it then re-ran update-rc.d and things looked a bit better. I suspect that I'd be better off abandoning the FDOMizer script and reinstalling the latest version, which seems a pity because update scripts are a great idea. Cheers, Jonathan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is Openmoko working on their 'back to basics' plan?
John, this new Update is an excelent move in several aspects. Keep it going, and thank you very much!! Citando John Lee [EMAIL PROTECTED]: Dear community, http://onlinedev.blogspot.com/2008/10/is-openmoko-working-on-there-back-to.html And please read my comment below. I have to say I don't like opinions like this but I will take it as a result of high expectation. We will keep sending to the public list once we have something, commit to public scm, etc. but we certainly won't do _weekly_ release. For now please be patient and let the engineers work. Now for the status update this week: Tick merged the qtopia echo patch (#1267), it works, no echo but the audio sounds a little bit less 'vivid' (not sure if this is the right word). He is now working on the touch screen usage, see http://lists.openmoko.org/pipermail/devel/2008-October/002712.html Olv and Erin is working on reducing boot time. Currently it's reduced from 2:35 (Om2008.9) to around 1:40. One minute less in one week, and Olv just got back from hospital last Monday. We will merge this into OE once we get it organized properly. Jeremy is working together with kernel guy (aka Matt Hsu) to look into the possible improvement, namely take a screenshot and show it first during resume. It's a common technique in mobile phone. Julian is working on the python loader. He is new to python but he got very good helps here in the office such as Guillaume, etc. He still got some distro work to finish so it's going to take a while before he can work full time on this. Currently we have a major blocker #2071. It can be solved by update EFL, but no icons will show up in illume. This seems to be a different bug, but we are having an evas-native related issue on the build server so the EFL packages are not updated correctly in downloads.openmoko.org. This prevents people from confirming it and fire another bug. EFL ABI changed along with the svn rev increment last week, so Installer and Locations won't work without rebuilding. Although people already got reassigned, but nobody will give Om2008 love except us and holger, so we will fix the issues above and update testing repo soon. Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Citando Kishore [EMAIL PROTECTED]: Since i got my neo rather recently, i have only tried 4.4.1. Is 4.3 still the better choice? A couple of days ago i lost my daily use phone (motoming A1200) and so i now need to use the FR as my daily phone. I've been using ASU (OM2008.9) since the beginning as my daily and only phone for months now, without great problems. It stinks for SMS texting, and it is a PITA to find a contact on the list (both of these are bad designs of Qtopia), but otherwise it does the job well. The only big problem is a denial-of-service that happens because os resume problems... sometimes I get an SMS or some other event that wakes up the phone, and if I don't touch the screen, it stays awake until the battery dies. This is why sometimes I wake up to a dead phone, even though I went to bed leaving it almost fully charged. :( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Community newsletter, October 4th to 19th
Excellent report, Minh! I've been having too little time to follow the traffic, you're a life saver! :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the basics: improving user experience
I agree with you partly; the main efforts should go into getting the new framework out - *as long as it runs on a rock-solid core system*. So I support the idea of accelerating the FSO integration... but in the meantime people have to use the sucking Qtopia ware in their everyday life, because there is no realistic alternative. FSO is still very incomplete at the user level. Today, the complete system is not reliable and the reliable system is not complete at all. If you fix the core and qtopia now, everybody gets a working phone, and FSO gets a more reliable development core. You favor the users, which are the noisier people. ;) If you jump start FSO into main distro, there will still not exist a complete system that can be used everyday. You favor the developers, who could wait a little more (but not long!) and ARE ALSO USERS. So please just make it work solidly, and then integrate FSO. :) Citando Neil Jerram [EMAIL PROTECTED]: 2008/10/16 Riccardo Centra [EMAIL PROTECTED]: Why Qtopia? I prefer that you release the next minor update ( aka 2008.10 ) and focus all works on paroli and tichy. The new framework is pretty usable and stable. I agree that you should not spend time on Qtopia. Even though I use Qtopia most of the time, I would prefer you to focus all your efforts on the lower levels (up to and including the FSO dbus interfaces) until they are rock solid. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the basics: improving user experience
An important note to the people who are experiencing all-round instability: I haven't had many problems with phone calls or SMS. I believe the critical point was to disable QPE's file search upon bootup [1]. Before I did that, I had all kinds of mysterious problems (including PIN), derived from the fact that the Neo's CPU was starving for cycles. To make matters worse, it would suspend before the indexing job was done, and so the Neo would not have enough CPU power to correctly process incoming calls and messages when it resumed. After disabling that QPE stuff, it basically works. [1]: http://n2.nabble.com/No-pin-dialog--qpe-tp685679p685679.html Citando John Lee [EMAIL PROTECTED]: What do you want us to work on? Prioritized: 1 - Solve the call quality problems (echo, buzzing, volume) for 99% of the users. 2 - Solve the illume resume problems. They have been talked about over and over, but unfortunately the information is scattered and imprecise. the tickets themselves have misleading info (I should know, I helped confuse you...), so maybe this deserves a new single ticket, where everyone contributes with more exact information; 3 - Get the wifi driver corrected, so that it does not create link association and stability and problems; 4 - Finish/validate implementation of the networking stack (all the way up to resolv.conf and friends); 5 - Merge the GPRS muxer into the stable distro, so that it works out of the box; 6 - Integrate the main applications with the power management: if QPE wants to index the whole friggin' filesystem right after boot, then give it time to do so before going into suspend; if you don't, it just bogs down the CPU for many suspend/resume cycles, creating all sorts of problems, and we don't know what is going on... 7 - Accelerate Qt applications - they respond so slowly that a normal user will shoot itself in the foot everyday (i.e. pushing the Answer button twice because it didn't appear to respond, effectively killing the call; or taking the phone to the ear after pushing Answer and having it rind loudly one last time in the ear); 8 - Work with the people of FDOM to integrate the best workarounds and hacks - they did the work already, just use it. 9 - Get all the bluetooth support organized out-of-the-box. I haven't played with it in a long time, but it looked like black voodoo to get a simple pairing and OBEX exchange going... forget about PAN!... 10 - Put a speaker button on the dialer app. This is my only GUI desire for now... Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the basics: improving user experience
I can see there are at least 2 distinct types of user of OM: A - I need a working phone now, the uber-cool PDA stuff can wait; B - OM is a groundbreaking project, I don't care about telephony, let's press the revolution! As much as I am divided among the two views, I think OM must oblige to its responsibility towards the users who have paid for their hardware, and keep its promise of a working phone. I don't think that making the core system work (including a little hacking of the Qtopia stuff) is a waste of time; any insight that is gained here can immediately be applied to FSO. OM2008.x will simply serve as a real-world testbed (one that is everyday usable!). When FSO comes along, it will already have the necessary corrections... Citando Didier Raboud [EMAIL PROTECTED]: Vasco Névoa wrote: I agree with you partly; the main efforts should go into getting the new framework out - *as long as it runs on a rock-solid core system*. So I support the idea of accelerating the FSO integration... but in the meantime people have to use the sucking Qtopia ware in their everyday life, because there is no realistic alternative. FSO is still very incomplete at the user level. Today, the complete system is not reliable and the reliable system is not complete at all. If you fix the core and qtopia now, everybody gets a working phone, and FSO gets a more reliable development core. You favor the users, which are the noisier people. ;) If you jump start FSO into main distro, there will still not exist a complete system that can be used everyday. You favor the developers, who could wait a little more (but not long!) and ARE ALSO USERS. So please just make it work solidly, and then integrate FSO. :) Well... I would rather let a bit more freedom to the team : if you (as in the team which will make the iFoan obsolete) think that breaking useability or functionality or anything else could serve the cause : do it ! Please decide your roadmap and make it public ! I (personnally) don't care if I am not able to use my Neo as a phone (and anything else possible) for 2-3-4-5 months : I have a working phone. BUT, what I would like to know is _when_ I will get _what_ functionality. I you think that breaking the whole stuff for a moment will serve a precise goal, please do it ! Regards, OdyX -- Swisslinux.org - Le carrefour GNU/Linux en Suisse - http://www.swisslinux.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flashing in (K)Ubuntu Linux 64bits
That's very strange to me... I've got Ubuntu 64bits, and no such problems. I just turn on the FR in the NOR bootloader (AUX-POWER, not POWER-AUX), and then go right ahead and use dfu-util without having to specify the device number... if the machine does not detect it, relaunch dfu-util. Maybe you guys have some USB hardware inside your machines that is capable of DFU (weird, but possible on laptops)... try dfu-util -l without the FR plugged in. Citando Patrick Beck [EMAIL PROTECTED]: Hello jotalix, i think you have the same problem as me, when i start to flash my Freerunner. dfu-util has detected two devices (./dfu-util -l) so i have to select one with the parameter --device. For example = ./dfu-util -a rootfs --device listed-id -R -D image.rootfs with kind regards Patrick Am Donnerstag, den 16.10.2008, 04:13 -0700 schrieb jotalix: Kubuntu, 64bits Hi, I am able to browser inside Neo Freerunner gta02, i do ssh [EMAIL PROTECTED], and do whatever i need inside. But i want to flash it to a recent version, and here comes the problem, i can only use dfu-util with my Neo on bootloader ,and while on bootloader kubuntu dont recognize it as a USB device whatever,... so how can it be possible to flash it? best regards, jotalix ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.1
I'm getting this error on OM2008.9 stable: openmoocow: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory Solved with opkg install libsdl-1.2-0 Thanks for this cute toy!!! :D Remark: shouldn't it moo both ways (up and down)? presently it only moos when I turn it back to upright position... :( Citando Thomas White [EMAIL PROTECTED]: I'm pleased to be able to announce version 0.1 of my advanced accelerometer and audio framework testing system, OpenMooCow. Available from http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/ When installed and run, OpenMooCow displays an artistic rendition of a fine specimen of Friesian dairy cattle. Invert the device and return it to an upright orientation to experience the pinnacle of audio rendering kwality. The sound effect can be altered by putting a suitable WAV file in /usr/share/openmoocow/moo.wav. A credit is due to Chris Hendricks who is the author of the original sound file (obtained from www.flashkit.com). Comments/abuse to this address. Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelsense.org (accelerometer-based gestures)
I forgot to mention: 7 - device rotation (for screen orientation and OpenMooCow) :) Citando Vasco Névoa [EMAIL PROTECTED]: Hi Paul. Your tenacity is indeed an example. Congratulations on the fusion of your academic and hacking lives! :) I don't want to burden you even more, but I'd like to remind you of a couple of details that may turn out to be important in the long run. One thing I would like to see come true is the implementation of an accelerometer framework that is flexible enough to accommodate all kinds of usage, not just gestures, and you are basically sitting on it (horay!!!). :) Examples: 1 - human gestures; 2 - seismic vibrations (distributed earth quake detection), see [1]; 3 - travel dead reckoning, whether of humans, human-powered vehicles, or motorized vehicles; 4 - road comfort level and trail quality level assessment (Z-axis vibration for geo map tagging); 5 - morse tapping (for awkward emergencies, you never know...); 6 - anything else you may think of in the future... My point is, please at least _try_ to include in your design some kind of easily extensible framework, possibly allowing dynamic plugins or at least compile-in modules, and package your specific gestures work as the first modules. And obviously, the ability to support multiple kinds of listener clients at the same time. I know it is a lot to ask, but I think it is very well worth it. The future community will thank you very much! :) Happy hacking!!! :D [1] http://n2.nabble.com/Idea-for-Openmoko-application%3A-seismic-sensor-network-tp1106366p1106366.html Vasco. Citando Paul V. Borza [EMAIL PROTECTED]: Hi everyone, A couple of people asked me whether I will or won't continue my project on accelerometer-based gestures. My answer was always yes, and to make that clear, I've bought accelsense.com, and accelsense.org. The code has moved from http://code.google.com/p/accelges/ into a GIT repository located at http://repo.accelsense.org. I'm now in the first year of masters, and I've managed to get two of my courses into the accelerometer-based gestures (i.e. to implement this as homework). From now on, my professors require me to use SOMs (i.e. self-organizing maps, a type of neural networks), instead of hidden Markov models. A couple of you guys asked whether the efficiency and speed can be improved using HMMs. Again, the answer is yes, just that I don't have time to work on the HMM implementation anymore. Just wanted to let you know that from now on, I'll focus exclusively on working with the Neo, rather than the Wii to test the gestures; and make them smooth and natural. Nokia is using SOMs for gesture recognition in mobile phones, so we should be on the technology wave as I can tell (still, I'm just one guy). What I'll focus on in the 0.2 release: * use some code from the rotate application that is flying around. * keep the current Dbus system for interaction. * 10% of CPU (it's now using 20%), and yes it's doable. * no GUI, but change the text console UI to be something like 'top', and not just printf hundreds of xyz data. * reintegrate with matlab-compatible diagrams. * will still be in C99 and under LGPL. * math formulas that are used in code will have a link to http://wiki.accelsense.org/wiki/page and the formula will be written in LaTex. * some of you gave me advices on how to improve the organization of the project, will also do that. * some dependencies aren't checked, there are too many you say, will be removed. * integration with the freesmartphone.org Dbus FSO communication system (I've seen that it grew since I last checked it). * implementation of self-organizing maps. Bottom line: I'll be trying turn it in a mature project ;) You can do interesting things with SOMs, like Nokia was doing: detecting when the user climbs down, up or walks, just using an accelerometer. Thanks, Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelsense.org (accelerometer-based gestures)
Hi Paul. Your tenacity is indeed an example. Congratulations on the fusion of your academic and hacking lives! :) I don't want to burden you even more, but I'd like to remind you of a couple of details that may turn out to be important in the long run. One thing I would like to see come true is the implementation of an accelerometer framework that is flexible enough to accommodate all kinds of usage, not just gestures, and you are basically sitting on it (horay!!!). :) Examples: 1 - human gestures; 2 - seismic vibrations (distributed earth quake detection), see [1]; 3 - travel dead reckoning, whether of humans, human-powered vehicles, or motorized vehicles; 4 - road comfort level and trail quality level assessment (Z-axis vibration for geo map tagging); 5 - morse tapping (for awkward emergencies, you never know...); 6 - anything else you may think of in the future... My point is, please at least _try_ to include in your design some kind of easily extensible framework, possibly allowing dynamic plugins or at least compile-in modules, and package your specific gestures work as the first modules. And obviously, the ability to support multiple kinds of listener clients at the same time. I know it is a lot to ask, but I think it is very well worth it. The future community will thank you very much! :) Happy hacking!!! :D [1] http://n2.nabble.com/Idea-for-Openmoko-application%3A-seismic-sensor-network-tp1106366p1106366.html Vasco. Citando Paul V. Borza [EMAIL PROTECTED]: Hi everyone, A couple of people asked me whether I will or won't continue my project on accelerometer-based gestures. My answer was always yes, and to make that clear, I've bought accelsense.com, and accelsense.org. The code has moved from http://code.google.com/p/accelges/ into a GIT repository located at http://repo.accelsense.org. I'm now in the first year of masters, and I've managed to get two of my courses into the accelerometer-based gestures (i.e. to implement this as homework). From now on, my professors require me to use SOMs (i.e. self-organizing maps, a type of neural networks), instead of hidden Markov models. A couple of you guys asked whether the efficiency and speed can be improved using HMMs. Again, the answer is yes, just that I don't have time to work on the HMM implementation anymore. Just wanted to let you know that from now on, I'll focus exclusively on working with the Neo, rather than the Wii to test the gestures; and make them smooth and natural. Nokia is using SOMs for gesture recognition in mobile phones, so we should be on the technology wave as I can tell (still, I'm just one guy). What I'll focus on in the 0.2 release: * use some code from the rotate application that is flying around. * keep the current Dbus system for interaction. * 10% of CPU (it's now using 20%), and yes it's doable. * no GUI, but change the text console UI to be something like 'top', and not just printf hundreds of xyz data. * reintegrate with matlab-compatible diagrams. * will still be in C99 and under LGPL. * math formulas that are used in code will have a link to http://wiki.accelsense.org/wiki/page and the formula will be written in LaTex. * some of you gave me advices on how to improve the organization of the project, will also do that. * some dependencies aren't checked, there are too many you say, will be removed. * integration with the freesmartphone.org Dbus FSO communication system (I've seen that it grew since I last checked it). * implementation of self-organizing maps. Bottom line: I'll be trying turn it in a mature project ;) You can do interesting things with SOMs, like Nokia was doing: detecting when the user climbs down, up or walks, just using an accelerometer. Thanks, Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Weekly Engineering News 41/2008: back to the basics
I couldn't be happier!!! OM is listening indeed. :D I know a few people will probably be disappointed because the eye-candy won't get much attention for the next few months, but I know that as soon as everybody start reaping the benefits of the Neo as a lean-and-mean-robust-machine then our love for the OM project and the faith on OM products will grow exponentially, not only inside the community, but also outside. We will finally be able to show the public what this project is about, without suffering inappropriate comments such as what, you can't pick up a call on your new phone??... ;) People often fail to see the beauty when in presence of a small spec of dirt. The day I see my Neo booting in 5 seconds or less with a rock-solid audio and networking stack (including wifi) and no standby/resume problems... Woohooo, I'll fly from Portugal to Taipei myself and pay a round of beers to the OM people!!! :D :D Citando Risto H. Kurppa [EMAIL PROTECTED]: Hi! Just want to make sure everyone knows that the weekly engineering news has been released again, see http://lists.openmoko.org/nabble.html#nabble-td1336450|a1336450 I want to highlight this: We decided to focus our engineering on just the basics, even less eye candy: Robust kernel, fast boot time, basic telephony with great audio quality, powerful configuration from the command line, hardware quality. That's it. We will stop working on our Installer, Locations, Diversity and Settings applications. We will get back to all this when the rest is rock solid, but now is not the time. Feel free to pickup any of these projects in the meantime I suppose this is generally a good thing to let the community do what it can do (as long as community has the tools and so on to do it) and Openmoko focus on the core stuff. Comments? r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Echo issue on OM2008.08 solved
Thanks Treviño!
However, qpe complains of binary compatibility:
Coult not load /opt/Qtopia/plugins/phonevendors/libficgta01vendor.so
errorString() The plugin
'/opt/Qtopia/plugins/phonevendors/libficgta01vendor.so' uses
incompatible Qt library. Expected build key arm-angstrom-linux-gnueabi
What can I do to make QPE take the new library?
Citando Matthias Apitz [EMAIL PROTECTED]:
El día Wednesday, October 15, 2008 a las 08:18:40AM +0200, Marco
Trevisan (Treviño) escribió:
Here you are [1]. It includes also the mwester fix for re-registering
network and my workaround for GSM firmware crash. I hope it won't have
any incompatibility with your installed Qtopia...
[1]
http://downloads.tuxfamily.org/3v1deb/openmoko/libficgta01vendor-echo-cancellation.so.tar.gz
Thanks for this. I've installed it this way:
# cd /opt/Qtopia/plugins/phonevendors/
# mv libficgta01vendor.so libficgta01vendor.so.orig
# mv ~/libficgta01vendor.so .
# /etc/init.d/xserver-nodm restart
interestingly the restart did not asked again for the PIN of the SIM (a
full re-boot does);
during outgoing call one now hears some noise like you have sometimes
when radio wafes of a GSM is affecting a normal phone call;
when I change in gsmhandset.state the section 'control.4' to values
control.4 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 127'
iface MIXER
name 'Speaker Playback Volume'
value.0 127
value.1 127
}
the outgoing RING tone nearly killed my ear; with 111 for value.[01] it is
fine, but with the above described noise; what is your
gsmhandset.state file for
this? thx again
matthias
--
Matthias Apitz
Manager Technical Support - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e [EMAIL PROTECTED] - w http://www.oclc.org/ http://www.UnixArea.de/
b http://gurucubano.blogspot.com/
A computer is like an air conditioner, it stops working when you open Windows
Una computadora es como aire acondicionado, deja de funcionar si
abres Windows
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Weekly Engineering News 41/2008: back to the basics
You, me, and Schindler makes 3. I guess by the time this actually happens, it'll be a large party!! :) Citando Rui Miguel Silva Seabra [EMAIL PROTECTED]: On Wed, Oct 15, 2008 at 02:01:01PM +0100, Vasco Névoa wrote: The day I see my Neo booting in 5 seconds or less with a rock-solid audio and networking stack (including wifi) and no standby/resume problems... Woohooo, I'll fly from Portugal to Taipei myself and pay a round of beers to the OM people!!! :D :D I'll join you! That way even more rounds of beer happen ;) Rui -- Wibble. Today is Pungenday, the 69th day of Bureaucracy in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] How to export Vcf Contacts from FR?
Great! Now I know which client to use, let's play!!! :)
I've spent 15 minutes reviving my SQL (which I had forgotten for at
least 5 years), and this is what I have so far:
*
sqlite3 /home/root/Applications/Qtopia/qtopia_db.sqlite 'Select distinct
nickname, title, firstname, middlename, lastname, suffix, profession,
b_webpage, company, office, department, jobtitle, default_email,
phone_number, h_webpage, spouse, gender, birthday, anniversary from
contacts, contactphonenumbers where
contacts.recid=contactphonenumbers.recid;' | sed 's/|/\t/g'
addressbook.txt
*
This creates an addressbook tab-delimited-file with all the fields I
thought where important for each contact (some info may be missing,
check the columns and tables).
Each contact that has more than one phone number will appear multiple
times because I haven't yet come up with a clean way to show the join
between the contacts and contactphonenumbers tables, so for now it
just duplicates the whole line, with the only difference being the phone
number.
Anyone versed in SQL will be able to hack this into a full VCF file
generator... or you can just go the Python way (but I prefer to use the
nice tools already in place) :)
Your turn! ;)
Paul wrote:
Hey Vasco,
You mean creating VCF's from the sqlite-data in a backup?
Would be interesting to play with. I could envision a slq-script that
dumps the data into a file and then a bash or python script that puts
things in the proper format. That's not too difficult, if sqlite plays
nice.
I had thought about that too, but I can't find an SQLite client in OM
repos to create the necessary script.
How can we talk to SQLite on OM without going the full C/C++ and
respective libs way? Python maybe?...
I found sqlite3 on my desktop pc, which makes things a lot easier. I
think that is included on anyone's Linux box these days, and on
www.sqlite.com/download there are also precompiled binaries for Mac and
Windows. You need sqlite version 3 for the .sqlite files on the FR.
I've been playing a bit with it: copied a .sqlite file from the
Freerunner to my machine and using sqlite3 I can pull information from
it quite easily:
echo .tables | sqlite3 qtopia_db.sqlite
appointmentcategories contactpresence mimeTypeMapping
appointmentcustom contactspimdependencies
appointmentexceptions content servicehistory
appointmentscontentPropssimcardidmap
callhistory currentsimcard simlabelidmap
callhistorytimezone databaseProperties sqlsources
categories defaultMimeApplication syncServers
categoryringtoneemailaddresses taskcategories
changelog favoriteservicestaskcustom
contactaddressesgoogleidtasks
contactcategories locationLookup versioninfo
contactcustom mapCategoryToContent
contactphonenumbers mimeTypeLookup
echo .dump contactphonenumbers | sqlite3 qtopia_db.sqlite
BEGIN TRANSACTION;
CREATE TABLE contactphonenumbers ( phone_number VARCHAR(100) NOT
NULL, recid INTEGER, phone_type INTEGER, FOREIGN KEY(recid)
REFERENCES contacts(recid) );
INSERT INTO contactphonenumbers VALUES('04x875',83886113,1);
INSERT INTO contactphonenumbers VALUES('07x693',83886209,1);
INSERT INTO contactphonenumbers VALUES('+3167678',83886277,257);
INSERT INTO contactphonenumbers VALUES('049275',83886193,1);
INSERT INTO contactphonenumbers VALUES('118',83886361,1);
INSERT INTO contactphonenumbers VALUES('+316244',83886365,1);
INSERT INTO contactphonenumbers VALUES('+3162233',83886357,1);
CREATE INDEX contactphonenumbersbytype ON contactphonenumbers
(phone_type, phone_number);
CREATE INDEX contactphonenumbersindex ON contactphonenumbers (recid);
CREATE INDEX contactphonenumbersnumbers ON contactphonenumbers
(phone_number, recid);
CREATE INDEX contactphnenumberscontacts ON contactphonenumbers (recid,
phone_number);
COMMIT;
I can imagine a python script on the desktop/laptop that would read all
the dumps, disect all the insert statements, combine the information
based on the recid attribute and after pulling all that together, write
out Vcards.
Note that I am using qtopia. I am not certain if the structure on
OM2008.x is identical. If that is the case, I can imagine a config file
per distribution, mapping attribute-names to the necessary Vcard
entries. (I have a lot of imagination.) You'd then run the python script
with a parameter telling it what config/mapping to use.
I am sure I can write something like that. I am however not sure how
long it would take me, as my order for 36-hour days has still not been
fullfilled. *grin*
What do you (or anyone) think of this?
Paul
Re: [OM2008.9][GTA02] a simple and quick GPS logger
I noticed the webmail interface screwed up the line breaks, so this time the scripts are attached. Here comes version 2. Changes: - Configured the u-blox chip to send only relevant messages; - Configured the u-blox chip to send 4 measurements per second instead of just one; - Don't try to power on or reconfigure the chip if it is already on; - Filter invalid messages (without a fix) out of the log files. To know how to generate the *.ubx files I use here, visit the wiki [1]. [1]: http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#Configuration_for_a_higher_sampling_rate Enjoy. GpsLogOn.desktop Description: application/desktop GpsLogOff.desktop Description: application/desktop om_suspend_functions.sh Description: Bourne shell script log_gps_track.sh Description: Bourne shell script CFG-MSG-GPGLL-OFF.ubx Description: Binary data CFG-MSG-GPGSA-OFF.ubx Description: Binary data CFG-MSG-GPGSV-OFF.ubx Description: Binary data CFG-MSG-GPVTG-OFF.ubx Description: Binary data CFG-MSG-GPZDA-OFF.ubx Description: Binary data CFG-RATE-2HZ.ubx Description: Binary data CFG-RATE-4HZ.ubx Description: Binary data ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] How to export Vcf Contacts from FR?
Paul wrote: Timo Jyrinki wrote: Does anyone know how to not only make a backup, but to export back to VCF format from Qtopia/Om2008.8? I now added a section for it at http://wiki.openmoko.org/wiki/Import_Vcf_Contacts - the 2007.2 section has a script that handles it. I wouldn't want to actively change the addressbook if I cannot export from it to some standard format if I eg. change to FSO (or even back to 2007.2 / SHR!). You mean creating VCF's from the sqlite-data in a backup? Would be interesting to play with. I could envision a slq-script that dumps the data into a file and then a bash or python script that puts things in the proper format. That's not too difficult, if sqlite plays nice. Paul I had thought about that too, but I can't find an SQLite client in OM repos to create the necessary script. How can we talk to SQLite on OM without going the full C/C++ and respective libs way? Python maybe?... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.8 default dialer crash on # or *
Treviño, can you please attach whatever patch you have for this on the Trac ticket (#1832, I think)? There are at least 3 tickets open with relation to this problem, and Holger is asking where is the patch... please put it up, even if it is not finished. I'm sure he will know what to do. :) Thanks! Marco Trevisan (Treviño) wrote: Holger Freyther wrote: On Thursday 18 September 2008 19:05:51 Marco Trevisan (Treviño) wrote: Ok, I was right... The latest upgrade to phonevendor plugin in git blocked it [1] Grab this [2] and put it in /opt/Qtopia/plugins/phonevendors. Restart the phone (reloading qpe wasn't enough to me) and it should work. [1] 563d5f4c781efe1a11680c6a055b409034b528ab [2] http://downloads.tuxfamily.org/3v1deb/openmoko/qtopia-ussd-support-phone-ve ndor.tar.gz Source? Patch? GPL? You're right. Completely. I generally never release binaries without diffs, but the patch I've with me is so bad and I'm so busy with my personal tasks that I had no time to upload anything in the last days. I'll try to do this as soon as I can. Sorry! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: accelerometer jitter
Joel Newkirk wrote: Sorry. ;) Near-stationary, power consumption immaterial, as accurate as possible. As a project to get my feet wet doing ground-up development (probably Python, which I need to learn) for the Freerunner (instead of just cross-compiling and fixing issues therein) I wanted to write a software 'bubble-level' tool. Laid flat on a surface you see a bubble, off-centered as a 'real' bubble-level would be to indicate pitch. More generally, held with the side or back against a vertical or horizontal surface to display an indication of how close to level (or vertical) the surface is. Lots of incremental additions and changes possible, like Have you looked at the Accelerometer Game? It would maybe give you a good jump start. http://projects.openmoko.org/plugins/scmsvn/viewcvs.php/?root=accelgame I have the first version installed and it pretty much covers the basic functionality of a bubble-level, but has momentum and bouncing. Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About OpenMoko Rotate
I haven't looked at the code yet, but my instinctive approach would be to calculate the direction of the down vector (constant 9.8m/s2 acceleration) and then compare that to the phone's down direction. It is the difference between these two vectors that I am referring to. Even if the error is great, surely it is not superior to 45 degrees (a quarter turn)? Is this not the way it is done? Fox Mulder wrote: This is not so easy to do. The rotation comes out of a calculation of the values from acceleration sensors. There are no angle sensors for this operation. So there is no way of exactly say which angle the neo currently has instead these are just aproximations. Ciao, Rainer Vasco Névoa wrote: That's very cool. I appreciate the mod. :) I'm seeing something that looks like a bug (in both versions)... but I'm not sure if the accelerometers require calibration or something. With the FR in vertical position, if I tilt it counter-clockwise, it takes just over 90 degrees to get 'accel-rotate' to change the orientation; but if I tilt it even less than 10 degrees clockwise after that, it reverts back to the original orientation. Shouldn't the threshold be set at the midpoint angles (45, 135, 225, 315 degrees)? Anyway, good work to both coders, it's just what I wanted. :D Maybe someone cares to extend this simple app to use some kind of sexy morph instead of the disruptive xrandr rotation? 8-) Rui Miguel Silva Seabra wrote: Done. I've added a reference to it at http://wiki.openmoko.org/wiki/Rotate but my page about it is at http://blog.1407.org/2008/09/20/openmoko-rotate-now-using-libxrandr/ Users of Rotate, I've patched it so it doesn't use system+xrandr but simply call directly the xrandr function using libxrandr. This means: * quicker * less battery consumption Best, Rui On Fri, Sep 19, 2008 at 10:13:29AM +0100, Rui Miguel Silva Seabra wrote: Hi, I'm preparing a patch for using xrandr api directly in Rotate instead of system(). It's almost done but I can only code it at home time (which, for me, starts again in about 9 hours) :) This will be much better in terms of speed and battery life! Best, Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Idea for Openmoko application: seismic sensor network
Now that our phones have accelerometers and are Internet capable, how about contributing to the Quake Catcher Network? http://qcn-web.stanford.edu/Overview.html It is based on an open source project called BOINC (http://boinc.berkeley.edu/) and therefore I think OM would be a very nice addition to the sensor network. Maybe the Gestures Daemon could be expanded into something a little more generic (preferably integrated into FSO's Dbus API) and could filter the information, separating events by classes, like Rotation of the Down vector, Gesture, and Seismic Vibration (which are all mathematically different)... and so each client app (Rotate, Gestures Listener, BOINC, etc.) would pick up on the desired class of data. Just an idea... :) Vasco Névoa. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ASU 2008.9] Is it required to reflash, or opkg update upgrade is enough?
Alasal wrote: I think (by looking at the bugs that are fixed and aren't fixed) that the om2008.9 is the same as om2008.8 updated between 16 september and 18 september. Because on 18 september there were updates for the om2008.8 that aren't included by default in 2008.9. But the updates are also available for the 2008.9. So If you install om2008.9 you can directly update it. So this review is valid for the om2008.9: http://onlinedev.blogspot.com/2008/09/openmoko-om20088-status-review_16.html And if you update your om2008.9, this review is valid: http://onlinedev.blogspot.com/2008/09/openmoko-om20088-status-review_18.html Bottom line: - an updated 2008.8 is the same as an updated 2008.9 - an 2008.8 updated on 17 September is the same an an 2008.9 I'm not sure I trust that line of logic enough... Is there a way to check if we have the latest? If the opkg feeds have not changed, then it is logical that updated2008.8 = 2008.9 ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About OpenMoko Rotate
That's very cool. I appreciate the mod. :) I'm seeing something that looks like a bug (in both versions)... but I'm not sure if the accelerometers require calibration or something. With the FR in vertical position, if I tilt it counter-clockwise, it takes just over 90 degrees to get 'accel-rotate' to change the orientation; but if I tilt it even less than 10 degrees clockwise after that, it reverts back to the original orientation. Shouldn't the threshold be set at the midpoint angles (45, 135, 225, 315 degrees)? Anyway, good work to both coders, it's just what I wanted. :D Maybe someone cares to extend this simple app to use some kind of sexy morph instead of the disruptive xrandr rotation? 8-) Rui Miguel Silva Seabra wrote: Done. I've added a reference to it at http://wiki.openmoko.org/wiki/Rotate but my page about it is at http://blog.1407.org/2008/09/20/openmoko-rotate-now-using-libxrandr/ Users of Rotate, I've patched it so it doesn't use system+xrandr but simply call directly the xrandr function using libxrandr. This means: * quicker * less battery consumption Best, Rui On Fri, Sep 19, 2008 at 10:13:29AM +0100, Rui Miguel Silva Seabra wrote: Hi, I'm preparing a patch for using xrandr api directly in Rotate instead of system(). It's almost done but I can only code it at home time (which, for me, starts again in about 9 hours) :) This will be much better in terms of speed and battery life! Best, Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
(Wiki)(GTA02) Freerunner should have its own audio system wiki page
I think the page (1) has grown too much and too messy. Maybe it's time to break it apart into 1973 FR variants. I know that both systems have a lot in common, but unfortunately they are NOT equal. I propose that the info about the FR is moved into a new page (Neo_Freerunner_Audio_Subsystem) and that any common parts stay in the present page, being referenced by the new page. An example of different info between both devices is the alsa state files and alsa control channel numbers and names... this alone justifies a new page to avoid the confusion. So, if you can help me by replying with the best known good alsa state files and all other important audio info about the FR, I can quickly write the new page. Yes, I will filter the lists in search of this info, but I bet I will miss something important (I haven't been hacking the audio system), so please help me out as well if you can. Any other suggestions are welcome. (1) http://wiki.openmoko.org/wiki/Neo_1973_audio_subsystem Cheers, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: (Wiki)(GTA02) Freerunner should have its own audio system wiki page
The page is started. I'll keep working on it as time permits. Please criticise/correct/add if needed. http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem Vasco Névoa wrote: I think the page (1) has grown too much and too messy. Maybe it's time to break it apart into 1973 FR variants. I know that both systems have a lot in common, but unfortunately they are NOT equal. I propose that the info about the FR is moved into a new page (Neo_Freerunner_Audio_Subsystem) and that any common parts stay in the present page, being referenced by the new page. An example of different info between both devices is the alsa state files and alsa control channel numbers and names... this alone justifies a new page to avoid the confusion. So, if you can help me by replying with the best known good alsa state files and all other important audio info about the FR, I can quickly write the new page. Yes, I will filter the lists in search of this info, but I bet I will miss something important (I haven't been hacking the audio system), so please help me out as well if you can. Any other suggestions are welcome. (1) http://wiki.openmoko.org/wiki/Neo_1973_audio_subsystem Cheers, Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
(OM2008.8-update) (audio/GSM) alsamixer names
Hi. Some callers have been complaining my GSM microphone level is low, so I've been reading the threads about echo cancellation and alsa state files, but every time I walk into alsamixer I get lost. I'd like to suggest different names for the Alsa controls, because quite frankly I cannot relate to the ones I see in alsamixer. But first I'd like to ask you guys if you feel the same need as me. Do you feel comfortable with the present alsa channel names, or would you like them to be clearer? I think that these names are confusing and sometimes even misleading. They should be closer to the user... like for example, from (1) we know that the Voice interface is connected to the bluetooth interface; why not call it bluetooth?? The same goes for PCM; I know everybody knows that PCM means Pulse Code Modulated and that can only come from the CPU, but can't we make life easier on ourselves and call it CPU or SoC or System or something more obvious that says this is Linux's sound card? The Mic1 and Mic2 could be called HeadMic and BuiltInMic or something. This would make it clearer for everyone messing with these settings, and so would help accelerate the troubleshooting of this complex system. As to the more obscure controls, like the MUXers and the intermediate routing volume levels, I'd like them to be less distracting and more accurate; they are used for several things, so they should not be named for external objects; how about calling them their wolfson datasheet names, like LMSEL?... this way we wouldn't need to constantly try to decode the meaning of each of these things, we'd just open up the picture (1) and everybody would know precisely what is being talked about... Basically, I'm trying to propose a naming scheme that separates high-level stuff (like plain Headphones and Microphone volume) from low-level stuff (like routing in the mixers). This would allow us newbies to play in alsamixer without fear of breaking some obscure routing that may later come back to bite us in the ear. Does anyone know where the alsa channel names are defined (which file)? Oh, and I think I see a bug: the channel names Headphone and Speaker are exchanged, as far as I can see. Phone call volume is controlled via Speaker and SoC music play is controlled via Headphone; Isn't this supposed to be the other way around? Please confirm/deny. (1): http://wiki.openmoko.org/wiki/Neo_1973_audio_subsystem#ALSA_Channels Vasco Névoa. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[OM2008.8-update] latest image + old /home/root = no GSM [solved]
I've been using my uSDcard as /home. So far, no problem, I reflash the device and mount it as /home and there it goes. I've done this with testing and update images without much problems. But today I was surprised to see that after reflashing I had normal GSM network, and after mounting my card's old /home/root and rebooting it became impossible to get the phone working. I reverted back to the original /home, and it worked again. In the logread I found a few Qtopia messages complaining about wrong plugin versions. I ended up doing cp /home/root/.config/Trolltech.conf /media/card/root/.config/ and it solved it (qtopia keeps the lib versions inside this file). After restoring the card as /home in /etc/fstab and rebooting, the phone worked again. Hope this helps someone. vnevoa. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: context sensitive menus
Matt wrote: Michael 'Mickey' Lauer wrote: Am Saturday 06 September 2008 03:01:33 schrieb Matt: On Windows Mobile (pocket pc), a long tap is like a right click; it invokes a context sensitive menu. If text is selected, there are options for copy/paste/cut. Are there plans for something similar for OM ? We had this in OM2007.1, but lost it on the way. I'm not sure how generally useful this feature is. I think having an easy, intuitive, constant way to copy/paste text on a device with no keyboard, will always be useful. Furthermore, I'd like to know that a long tap on a phone number will always offer to Call Number, SMS, Lookup Contact, Add to Contacts. A long tap on selected text should offer to Save Note, Send SMS, Send EMail. A long tap on text which includes a date/time should offer to add an event in the calendar too. A long tap on an address should offer to find it on a map. I'm sure there are many other instances where a long tap on 'something' should allow an action to be performed with it. People should chime in if they support it. At the moment, the FR is bearly able to compete with an old Palm Vx in terms of intuitiveness. Yes, these are the things I miss the most after dumping my Windows Mobile for OpenMoko. We desperately need, at the very least, the copy-paste function. The phone message related functions are a must, and the location-related functions are a very desirable (but still a novelty to design) feature. ~ Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.8][testing][kernel] image and modules not in sync?
Now in ticket: https://docs.openmoko.org/trac/ticket/1967 [EMAIL PROTECTED] wrote: I've followed the discussion about dual booting, kernel packaging, and kernel vs. distros, and the conclusion I reach is that the devs are inclined to use (mostly-)monolithic kernels, leaving just the extras out in the sysfs modules dir. This is fine by me, but there seems to be a little mess here. There are modules in the file system that are not loadable because they are already built in. This is not a good thing, because it induces the user in error - I thought there was something wrong with the kernel or with the modules, when the problem is just a question of cleaning up the repository filesystem images. If the modules are built-in, they should not be present in the filesystem, IMHO. If a user follows the wiki howtos about networking, she may be trying to modprobe bnep for example, and scratching her head because bluetooth and l2cap won't load (let alone bnep). Only after grepping /proc/kallsyms I understood these modules where already built-in. duh! total time loss. So please clean up a little, ok? At least the fs images on the downloads server should be consistent with the given kernel. If an update breaks things, that another issue entirely. Thank you! Keep up the good work. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.8/testing] where is pand?
This is now being discussed in the support list. pand has been removed, dbus support is in place. Vasco Névoa wrote: Am I the only one to find that pand (the Personal Area Network daemon) is missing and that it is no longer possible to establish a bluetooth network connection with OM2008.8?... Vasco Névoa wrote: Up-to-date 2008.8/update with testing feeds here. I can't find the pand to establish a bluetooth network connection. Can anyone tell me which package installs it? Thx. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.8/testing] where is pand?
Am I the only one to find that pand (the Personal Area Network daemon) is missing and that it is no longer possible to establish a bluetooth network connection with OM2008.8?... Vasco Névoa wrote: Up-to-date 2008.8/update with testing feeds here. I can't find the pand to establish a bluetooth network connection. Can anyone tell me which package installs it? Thx. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: illume-config-illume on 2008.8-updates
Thanx Raster!! Finally got a decent keyboard. :) Geoff Ruscoe wrote: Thanks Raster I also want to send thanks to the Rasterman! You've done so much to help us all out. It is very appreciated. I now have a full keyboard and wrench (and screen saver too). thanks again! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[2008.8/testing] where is pand?
Up-to-date 2008.8/update with testing feeds here. I can't find the pand to establish a bluetooth network connection. Can anyone tell me which package installs it? Thx. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: saving and restoring GPS data for U-blox chip quicker startup
Abdelrazak Younes wrote: There is at least two that I know of, some ruby script: http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox And some python script in the FSO framwork. Look framework/subsystems/ogpsd/ Cool. What's the requirements to get alphaone's ruby scripts working in OM2008.8? Aside from opkg install ruby... I'd like to see the freerunner's GPS do the same any other GPS device does: save the almanac/ephemeris data to storage upon shutdown and restore it upon powerup. Right. I just receive my freerunner today. So I may start my own plan this week :-) Excellent. :) So, I took the protocol datasheet (http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm) and tried to coerce the chip into vomiting the stored information (we should take care to do it after working for at least 2 or 3 minutes with a good reception level). A better solution would be to just configure the Ublox to send the ephemerises and almanacs as soon as they are received. I didn't know that was even possible... great! A simple daemon would watch for these messages and store them appropriately when they are received. Makes sense. Yes. The FSO is capable of doing that AFAIU. I have some code that do that in C++ already, I'll publish them as soon as I port them to the FR. My code will be able to read and decode a number of messages, including raw data (pseudorange measurements). Wonderful. Just make sure you're not duplicating efforts with someone else... :) 2 - a simple hook into the UI gps on/off button script, forcing process (1) to ask for info and store it on file upon gps shutdown, and to rewrite that info into the chip on startup. I don't think we need any manual intervention here. The above described daemon should just be reading only the device. Another program should be responsible of writting the aid data as soon as the GPS is started. Ideally this program could also be able to write manually encoded messages based on commonly used formats for ephemerises (RINEX) and almanacs (Yuma). Who's working on this? I'd happily beta-test it. I will, hopefully in the coming weeks :-) Fine. Keep us posted! Abdel. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: saving and restoring GPS data for U-blox chip quicker startup
digger vermont wrote: On Sat, 2008-08-30 at 10:59 +0200, Abdelrazak Younes wrote: There is at least two that I know of, some ruby script: http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox And some python script in the FSO framwork. Look framework/subsystems/ogpsd/ I just looked. It's in ubx.py. There was also recently a warmstart patch committed. digger Nice! but that patch you mention is for FSO only, right? No ASU benefits there... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
saving and restoring GPS data for U-blox chip quicker startup
Hi all. I don't know how far anyone has gone in this subject, so I took the liberty to experiment. I'd like to see the freerunner's GPS do the same any other GPS device does: save the almanac/ephemeris data to storage upon shutdown and restore it upon powerup. I don't know much about GPS, but I imagine this would accelerate the startup, and it wouldn't hurt much if the device has changed geographical location in between (like after a plane trip, for example.) So, I took the protocol datasheet (http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm) and tried to coerce the chip into vomiting the stored information (we should take care to do it after working for at least 2 or 3 minutes with a good reception level). Basically: # Listen to the GPS port. Don't use gpspipe or any other complicated stuff because of internal filtering cutting the binary messages. U-blox binary protocol messages start with 0xB5 0x62. [EMAIL PROTECTED]:~# hexdump /dev/ttySAC1 | grep 62b5 # If you're suspicious of this, take a look at the direct output of cat /dev/ttySAC1 and you'll be convinced when you see the ASCII output temporarily replaced by binary garbage. :) # Ask the u-blox chip for it's stored gps data, by sending the AID-DATA poll message (equivalent to sending AID-INI + AID-HUI + AID-EPH + AID-ALM, we could send each one alone if desirable): [EMAIL PROTECTED]:~# ./ubxgen.py 0B 10 00 00 AID-DATA.ubx [EMAIL PROTECTED]:~# cat AID-DATA.ubx /dev/ttySAC1 # out pours the requested data... (down at the end of this message) Now, this is just a start for a proof of concept, and I think it has potential. The output is already in the same format it takes for input, and is separated into 4 different message categories, allowing us to modify some of the data if needed. So, what would be needed for this feature to be implemented? 1 - some process capable of writing and reading ublox-binary at /dev/ttySAC1; 2 - a simple hook into the UI gps on/off button script, forcing process (1) to ask for info and store it on file upon gps shutdown, and to rewrite that info into the chip on startup. Who's working on this? I'd happily beta-test it. My data (not really relevant, and probably incomplete because of the grep) 4c0 3030 2c38 3030 302c 2a30 4236 0a0d 62b5 500 4ba0 62b5 020b 0048 550 0007 d55d 62b5 310b 0008 0001 560 f745 62b5 310b 0008 0002 570 ff46 62b5 310b 0008 0003 580 0747 62b5 310b 0008 0004 590 0f48 62b5 310b 0008 0005 5a0 1749 62b5 310b 0008 0006 5b0 1f4a 62b5 310b 0008 0007 5c0 274b 62b5 310b 0008 0008 5d0 2f4c 62b5 310b 0008 0009 5e0 374d 62b5 310b 0008 000a 5f0 3f4e 62b5 310b 0008 000b 600 474f 62b5 310b 0008 000c 610 4f50 62b5 310b 0008 000d 620 5751 62b5 310b 0008 000e 630 5f52 62b5 310b 0008 000f 640 6753 62b5 310b 0008 0010 650 6f54 62b5 310b 0008 0011 660 7755 62b5 310b 0008 0012 670 7f56 62b5 310b 0008 0013 680 8757 62b5 310b 0008 0014 690 8f58 62b5 310b 0008 0015 6a0 9759 62b5 310b 0008 0016 6b0 9f5a 62b5 310b 0008 0017 6c0 a75b 62b5 310b 0008 0018 6d0 af5c 62b5 310b 0008 0019 6e0 b75d 62b5 310b 0008 001a 6f0 bf5e 62b5 310b 0008 001b 700 c75f 62b5 310b 0068 001c 770 f5a2 004d 8a90 62b5 310b 0008 001d 780 d761 62b5 310b 0008 001e 790 df62 62b5 310b 0008 001f 7a0 e763 62b5 310b 0008 0020 7b0 ef64 62b5 300b 0008 0001 7c0 ec44 62b5 300b 0008 0002 7d0 f445 62b5 300b 0008 0003 7e0 fc46 62b5 300b 0008 0004 7f0 0447 62b5 300b 0008 0005 800 0c48 62b5 300b 0008 0006 810 1449 62b5 300b 0008 0007 820 1c4a 62b5 300b 0028 0008 850 0001 ffea 7fa6 62b5 300b 0028 0009 880 0034 0001 312f 62b5 300b 0028 000a 8b0 000f dc57 62b5 300b 0028 000b 8e0 001b 0002 6f29 62b5 300b 0028 000c 910 001b ffd1 0a32 62b5 300b 0028 000d 940 000f 0023 5e7a 62b5 300b 0028 000e 970 0032 ffe2 4ccb 62b5 300b 0028 000f 9a0 ffda ffe9 f7a8 62b5 300b 0028 0010 9d0 ffed 000e 7eba 62b5 300b 0028 0011 a00 0004 0005 40f0 62b5 300b 0028 0012 a30 0039 ffed 0192 62b5 300b 0028 0013 a60 0014 0004 c1c7 62b5 300b 0028 0014 a90 001e 000d 676b 62b5 300b 0028 0015 ac0 001c 0006 faab 62b5 300b 0028 0016 af0 0016
Re: Order from Pulster
enaut wrote: Christoph Pulster schrieb: Hello, thanks to Openmoko Inc. (great job Harry!) we received the new batch of units in time. So EVERYBODY who got an order confirmation from me for delivery-batch 15.08. will get his Freerunner in the next days. In other words, we are busy all the day to ship all orders. Despite very long delivery times and sometimes late replys from my side, Applause to my Openmoko customers, you all are very patient, understanding and very kind and friendly persons, Chris www.pulster.de Openmoko Shop I recieved my Gummi bears yesterday :)... thx I was quiet exited about the package by pulster I opened it and the first you see is a small package of Gummi bears juhu :)... So I waited for more than a month and I can say, that it was absolutely worth it. So just be patient for another week or two. Meanwhile the software is getting better and better so the wow effect will be even bigger. enaut ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Oh yeah, I forgot to thank Christoph for the gummy bears too! Nice friendly touch! :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Where is ASU?
Hi folks. Sorry if I'm asking something too obvious, but I can't find the ASU images on http://buildhost.openmoko.org/daily/freerunner/... I see that all the links to ASU images in the mailing list end up in 404s... So, 2 questions: 1 - where are ASU images; 2 - what exactly is hosted in buildhost? FSO? Thanks in advance! Vasco. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
Hi. Sorry to barge in like this, but I don't quite understand the problem to begin with... Isn't open source code by definition protected against subsequent patents? It is part of the patenting process to search for conflicting publications; if they find any, then the candidate idea is not a novelty and cannot be patented. Publishing is the best weapon against (subsequent) patents: cheap and effective. I think we should just add some way to automatically timestamp every code check-in in a legally binding way, like using some outside certification entity's digital signature (that carries a legally recognizable timestamp). An open-source public repository is a valid publication of ideas, which are therefore not patentable. What do you think? - Mensagem Original - De: Sean Moss-Pultz [EMAIL PROTECTED] Data: Terça-Feira, 12 de Fevereiro de 2008, 4:25 Assunto: Re: Patents and OpenMoko Nils, Thanks a lot for such an indepth reply. I need to think about a lot of these points. Let me just comment on a few now... On 2/11/08 Nils Faerber wrote: [snip] Are there any existing options available to us now? Does anyone know of existing companies or organizations with a similar strategy that we can seek guidance or partnership. Again, I want to emphasize that we only want our patents to be used in defense. And what constitutes defense is something that we want to be able to define (and potentially even redefine when new threats arise). This is a noble aim but very very difficult to reach. Perhaps. But I think we should try our best... Speaking as a free software acitvist especially software patents are a complete no-go. Speaking as community guy I would say that with the software patents you would have to sign and publish a non-revocable community contract that sais quite explicitely for which use you would accept royaltee free use and of which patents. Only then the community would be safe. Else, at some later point in time, someone at OpenMoko/FIC might change their mind and try to make money from the patents. I think there is a way to get around this legal. We're getting some advice from the SFLC later this week. I'll keep everyone posted as to our plans. Thanks in advance for the help. My very quick advice: Don't get your hands dirty with patents, especially with software. You will loose a lot of credibility in the free software world and the benefit is questionable. With all due respect, I must disagree here. Not filing for patents, is hardly an option for a global company in this day and age. The larger we get, the more of target we become. I'm confident we can reach a solution that will be helpful for both our business and the community. I will keep you all posted as to our progress. Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Ponha a sua Vida em Grande Plano! 10% DESCONTO ADICIONAL para adesoes on-line. Clique aqui para saber mais http://www.iol.pt/correio/rodape.php?dst=0801301 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
