Re: Flashing qi broke my freerunner
Hi, I can confirm that with the modified qi bootloader I get the WSOD either at once or after seing the boot logo of SHR. I re-flashed the unmodified version to get rid of the issues. I got a GTA02 V5 model with the buzz fix applied. Cheers, Bernhard -- View this message in context: http://openmoko-public-mailinglists.1958.n2.nabble.com/Glamo-slowness-question-Glamo-transfer-speed-improvements-33-Video-sofdecoding-playing-profile-Glamo-tp5307224p5319820.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
Re: Flashing qi broke my freerunner - SOLVED
On 20. juli 2010 16:52, Helge Hafting wrote: [...] On reboot, the screen went white, and nothing more happened. Solution for bricked phone: Somehow, the kernel partition got wrecked during flashing. So, reflashing the kernel brought the phone back to life. (No, I did not make the mistake of flashing qi into the kernel paritition. But it got broken anyway.) Solution for recurring WSOD: With the 2+4+2 qi, WSOD seems to happen more often. And curiously enough, removing power (as in pulling the battery out), doesn't help. It is then guaranteed to reboot into WSOD. Strange that the phone is capable of keeping this state over poweroff - do qi and uboot write state into flash? The solution is to boot into NOR flash, and then select Poweroff from the menu. After that, I get a normal reboot without the WSOD. Graphics indeed seems a bit faster with this qi. :-) I hope the WSOD problems can be fixed in the kernel and/or the xserver. It happens without this qi too - perhaps not as often. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: Flashing qi broke my freerunner - SOLVED
Solution for recurring WSOD: That was no *OD, as the freerunner boots normally, except for not showing a display. So halting the system vie USB/ssh still works The solution is to boot into NOR flash, and then select Poweroff from the menu. After that, I get a normal reboot without the WSOD. Graphics indeed seems a bit faster with this qi. :-) I don't see a performance gain on my freerunner (latest SHR-U, 2.6.23.13). How do you all test this? I mean not becnhmark-wise but with a real-usage-example -- n...@el-hennig.de Lubarsky's Law of Cybernetic Entomology: There's always one more bug. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flashing qi broke my freerunner - SOLVED
With the 2+4+2 qi, WSOD seems to happen more often. And curiously enough, removing power (as in pulling the battery out), doesn't help. It is then guaranteed to reboot into WSOD. Strange that the phone is capable of keeping this state over poweroff - do qi and uboot write state into flash? The solution is to boot into NOR flash, and then select Poweroff from the menu. After that, I get a normal reboot without the WSOD. Graphics indeed seems a bit faster with this qi. :-) I hope the WSOD problems can be fixed in the kernel and/or the xserver. It happens without this qi too - perhaps not as often. i can confirm exactly the same findings. as JaMa stated, perhaps this will help to find the cause of WS altogether... Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flashing qi broke my freerunner - SOLVED
On 21. juli 2010 10:25, n...@el-hennig.de wrote: Solution for recurring WSOD: That was no *OD, as the freerunner boots normally, except for not showing a display. So halting the system vie USB/ssh still works The solution is to boot into NOR flash, and then select Poweroff from the menu. After that, I get a normal reboot without the WSOD. Graphics indeed seems a bit faster with this qi. :-) I don't see a performance gain on my freerunner (latest SHR-U, 2.6.23.13). How do you all test this? I mean not becnhmark-wise but with a real-usage-example 2.6.23? You meant 2.6.32? The performance gain is only for graphics operations, not for computation or filesystem activity. (This qi improves timing for the glamo graphics chip.) So try booting with normal qi and enhanced qi. In either case, look at operations that paints or scroll large parts of the screen. Get a feel of how much time is used - maybe you notice the difference. Or play videos, and check how high framerate you can get before the player drops frames. Or play graphics-intensive game like linball or duke nukem. If you can get them to work on today's SHR, that is. Currently, the necessary screen rotation does not seem to work well. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Flashing qi broke my freerunner - SOLVED
Hi, guys, Glad to hear no FR fried :) But you not really right that this timings are influence only to graphic. They should influence (may be a bit, but still influence) to usd access speed/cpu load too. I didn't measure that. Here have one idea to check, may be it'll fix that WS and rotation issues together, i'll report later if it'll be ok. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On 03. mai 2010 11:10, Jeffrey Ratcliffe wrote: On 3 May 2010 11:04, Dr. H. Nikolaus Schallerh...@goldelico.com wrote: Having navigation work inside tunnels would allow mapping them accurately for openstreetmap. And also have underground navigation - some tunnels have got intersections/roundabouts inside, with several possible exits. Would navit, tangogps, etc. need a new interface to access the sensors, or could the existing libraries be adapted to correct the GPS data with additional information from the extra sensors before handing it on to the GUI? The natural place for such software seems to be in gpsd itself - it already supports having several gps (position) devices. (Or possibly in a front-end to gpsd - depends on what the gpsd developer wants.) But too many processes / software layers is not good - it causes delays. navit, tangogps etc. should of course not need reprogramming, you can't fix every program out there. Especially not the proprietary ones. The software should simply pass through gps data as long as it arrives, and the precision is sufficient. This data can be used for continous calibration of the magnetic/inertial/odometer inputs. When gps precision drops below intertial precision, or when gps drops out completely, the software should keep sending position updates based on inertial data. On your display, the map software will then tell you that you have 0 satellites, but still update your location on the map. Another use: interpolate position between gps updates, so you can have a 10 FPS map if you like. As the software auto-calibrates the inertial system, it can know its precision. So it can report how the gps-less position data deteriorate over time, and perhaps stop when precision gets so bad that the inertial data is no better than assuming you just stopped at the point where you lost gps coverage. An inertial system with only accelerometers will go bad quickly, unless you have some really good accelerometers. A system with odometer and magnetic compass can keep you going for a long time and do better than the simple stopped due to missing gps signal. In particular, the odometer will know when you are standing still - you can only loose precision when moving. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On 03. mai 2010 13:05, Michele Brocco wrote: On 5/3/10, Helge Haftinghelge.haft...@hist.no wrote: [...] For cars, one can get USB equipment to read the odometer pulses (and lots of other stuff besides that.) A similiar sensor can be made for bicycles - having an input for that on the board would be very useful. (And given the slow cpu, a pulse counter so the software won't have to rely so much on pulse timing.) This is great for driving in tunnels. There are many mountains and tunnels where I live. Having navigation work inside tunnels would allow mapping them accurately for openstreetmap. And also have underground navigation - some tunnels have got intersections/roundabouts inside, with several possible exits. And then there are cities with too many tall buildings, and things like parking houses. In principle that would work. In practice I am afraid that will work for only short distances due to the noise of the sensors. In my opinion we should first focus on use cases in which short distance tracking is required. I think the success rate there may be higher and we can the build on our findings more complex applications. Personally, I will focus on that. I would be interested in seeing also other use cases implemented though. I think one approach can work for all. Software that auto-calibrates the other inputs while the gps signal is good, will know the precision of the other inputs. When gps drops out, it can provide location data until precision deteriorates into uselessness. This may not take long with a cheap accelerometer - but the software will automatically work for much longer if more precise equiopment is connected. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
shr-messages, bubble style ?
Hi folks, is there any project to change shr-messages GUI ? If you browse : http://trac.enlightenment.org/e/wiki/Elementary you can see a nice use of the bubble widget : http://download.enlightenment.org/att/wiki/Elementary/elm-app-02.2.png I think it would be cool to be able to view a discussion in shr-messages, and not only one isolated message. Xavier (currently learning python-elementary) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Am 21.07.2010 um 10:55 schrieb Helge Hafting: On 03. mai 2010 11:10, Jeffrey Ratcliffe wrote: On 3 May 2010 11:04, Dr. H. Nikolaus Schallerh...@goldelico.com wrote: Having navigation work inside tunnels would allow mapping them accurately for openstreetmap. And also have underground navigation - some tunnels have got intersections/roundabouts inside, with several possible exits. Would navit, tangogps, etc. need a new interface to access the sensors, or could the existing libraries be adapted to correct the GPS data with additional information from the extra sensors before handing it on to the GUI? The natural place for such software seems to be in gpsd itself - it already supports having several gps (position) devices. (Or possibly in a front-end to gpsd - depends on what the gpsd developer wants.) But too many processes / software layers is not good - it causes delays. Well, for 1 position per second delays it may be neglectable, but you are right - having everything in one middle-man daemon (gpsd) appears to be the best architecture for me. So it hides the complexity from the user-applications, and should be easily expandable. As far as I know, the kernel driver for the BMP085 barometric altimeter is already in some upstream kernel release candidate. So altitude information can be mixed between GPS and altimeter as well. navit, tangogps etc. should of course not need reprogramming, you can't fix every program out there. Especially not the proprietary ones. The software should simply pass through gps data as long as it arrives, and the precision is sufficient. This data can be used for continous calibration of the magnetic/inertial/odometer inputs. I would even suggest to use a Kalman-Bucy filter [1] for sensor integration so that it does not switch between two modes but does a soft transition. As far as I understand, a Kalman filter can also learn about (linear) errors, offsets and drift of sensors while multiple sensor data is available. It is definitively possible to write such a Kalman filter for a smartphone since a student has recently been awarded [2] by VDE Germany (sort of a local IEEE) for such a project. Nikolaus [1]: http://en.wikipedia.org/wiki/Kalman_filter [2]: (in German) http://www.br-online.de/studio-franken/aktuelles-aus-franken/jugend-forscht-robert-schaller-sonderpreis-vde-ID1273673737606.xml?_requestid=146846 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-messages, bubble style ?
On Wed, Jul 21, 2010 at 11:16, Xavier Cremaschi omega.xav...@gmail.com wrote: Hi folks, is there any project to change shr-messages GUI ? If you browse : http://trac.enlightenment.org/e/wiki/Elementary you can see a nice use of the bubble widget : http://download.enlightenment.org/att/wiki/Elementary/elm-app-02.2.png I think it would be cool to be able to view a discussion in shr-messages, and not only one isolated message. Xavier (currently learning python-elementary) opkg install opimd-utils And try opimd-messages. opimd-utils is my playground in testing opimd and python-elementary, and opimd-messages is an application which uses chat view ;) (btw. I don't know which version is available in shr-testing, but it's possible it's too old - opimd-messages should display contact list at beginning, if it does not, then you have old version) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Am Mittwoch 21 Juli 2010, 11:22:20 schrieb Dr. H. Nikolaus Schaller: Am 21.07.2010 um 10:55 schrieb Helge Hafting: On 03. mai 2010 11:10, Jeffrey Ratcliffe wrote: On 3 May 2010 11:04, Dr. H. Nikolaus Schallerh...@goldelico.com wrote: Having navigation work inside tunnels would allow mapping them accurately for openstreetmap. And also have underground navigation - some tunnels have got intersections/roundabouts inside, with several possible exits. Would navit, tangogps, etc. need a new interface to access the sensors, or could the existing libraries be adapted to correct the GPS data with additional information from the extra sensors before handing it on to the GUI? The natural place for such software seems to be in gpsd itself - it already supports having several gps (position) devices. (Or possibly in a front-end to gpsd - depends on what the gpsd developer wants.) But too many processes / software layers is not good - it causes delays. Well, for 1 position per second delays it may be neglectable, but you are right - having everything in one middle-man daemon (gpsd) appears to be the best architecture for me. So it hides the complexity from the user-applications, and should be easily expandable. As far as I know, the kernel driver for the BMP085 barometric altimeter is already in some upstream kernel release candidate. So altitude information can be mixed between GPS and altimeter as well. Well, not in a release candidate. The patch waits in Andrew Morton's MM tree to be sent upstream. This will probably happen after 2.6.35 has been released. In the meantime I will send patches against the SHR kernel to the shr-devel mailing list. Hopefully they will be included by default when the navigation board v2 becomes available. I started to document the features of the new board: http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2 This might be the right place to collect ideas or suggestions on how to use the new possibilities. Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Nice. Regards Sriranjan On Wed, Jul 21, 2010 at 10:23 PM, Christoph Mair m...@chonyota.net wrote: Am Mittwoch 21 Juli 2010, 11:22:20 schrieb Dr. H. Nikolaus Schaller: Am 21.07.2010 um 10:55 schrieb Helge Hafting: On 03. mai 2010 11:10, Jeffrey Ratcliffe wrote: On 3 May 2010 11:04, Dr. H. Nikolaus Schallerh...@goldelico.com wrote: Having navigation work inside tunnels would allow mapping them accurately for openstreetmap. And also have underground navigation - some tunnels have got intersections/roundabouts inside, with several possible exits. Would navit, tangogps, etc. need a new interface to access the sensors, or could the existing libraries be adapted to correct the GPS data with additional information from the extra sensors before handing it on to the GUI? The natural place for such software seems to be in gpsd itself - it already supports having several gps (position) devices. (Or possibly in a front-end to gpsd - depends on what the gpsd developer wants.) But too many processes / software layers is not good - it causes delays. Well, for 1 position per second delays it may be neglectable, but you are right - having everything in one middle-man daemon (gpsd) appears to be the best architecture for me. So it hides the complexity from the user-applications, and should be easily expandable. As far as I know, the kernel driver for the BMP085 barometric altimeter is already in some upstream kernel release candidate. So altitude information can be mixed between GPS and altimeter as well. Well, not in a release candidate. The patch waits in Andrew Morton's MM tree to be sent upstream. This will probably happen after 2.6.35 has been released. In the meantime I will send patches against the SHR kernel to the shr-devel mailing list. Hopefully they will be included by default when the navigation board v2 becomes available. I started to document the features of the new board: http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2 This might be the right place to collect ideas or suggestions on how to use the new possibilities. Christoph ___ 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: Introducing the Freerunner Navigation Board
On Wednesday 21 July 2010, Dr. H. Nikolaus Schaller wrote: Am 21.07.2010 um 10:55 schrieb Helge Hafting: On 03. mai 2010 11:10, Jeffrey Ratcliffe wrote: On 3 May 2010 11:04, Dr. H. Nikolaus Schallerh...@goldelico.com wrote: Having navigation work inside tunnels would allow mapping them accurately for openstreetmap. And also have underground navigation - some tunnels have got intersections/roundabouts inside, with several possible exits. Would navit, tangogps, etc. need a new interface to access the sensors, or could the existing libraries be adapted to correct the GPS data with additional information from the extra sensors before handing it on to the GUI? The natural place for such software seems to be in gpsd itself - it already supports having several gps (position) devices. (Or possibly in a front-end to gpsd - depends on what the gpsd developer wants.) But too many processes / software layers is not good - it causes delays. Well, for 1 position per second delays it may be neglectable, but you are right - having everything in one middle-man daemon (gpsd) appears to be the best architecture for me. So it hides the complexity from the user-applications, and should be easily expandable. It looks like gpsd has support for magnetometer, accelerometer and gyro readings in its ATT (vehicle-attitude) object. The object also contains device name, so each sensor should appear as a different device. Now we need a gpsd driver for each device. http://gpsd.berlios.de/gpsd.html As far as I know, the kernel driver for the BMP085 barometric altimeter is already in some upstream kernel release candidate. So altitude information can be mixed between GPS and altimeter as well. This would come under gpsd's TPV object as altitude and/or climb rate I guess, unless they can be persuaded to add pressure to the object. I don't know what the best way to deal with altitude offset due to weather would be. navit, tangogps etc. should of course not need reprogramming, you can't fix every program out there. Especially not the proprietary ones. The software should simply pass through gps data as long as it arrives, and the precision is sufficient. This data can be used for continous calibration of the magnetic/inertial/odometer inputs. I would even suggest to use a Kalman-Bucy filter [1] for sensor integration so that it does not switch between two modes but does a soft transition. As far as I understand, a Kalman filter can also learn about (linear) errors, offsets and drift of sensors while multiple sensor data is available. It is definitively possible to write such a Kalman filter for a smartphone since a student has recently been awarded [2] by VDE Germany (sort of a local IEEE) for such a project. That's what the ground vehicle strapdown systems I was looking at several years ago did. They took GPS, a pulse input for vehicle speed and a compass, used a Kalman filter to estimate position, heading and velocity, and gave a single NMEA output. It's probably worth a look at the IMU work from the guys doing DIY UAVs. They're combining gps, magnetometer, accel and gyro signals on small processors. http://diydrones.com/forum/topics/has-anybody-achieved-a AFAIK there's nothing in gpsd for combining signals like this. It may be possible to make gpsd driver for a virtual device that takes input from other gpsd devices and combines them. Another option is to do the combination in something implementing the geoclue API, but that doesn't include orientation yet. Nikolaus [1]: http://en.wikipedia.org/wiki/Kalman_filter [2]: (in German) http://www.br-online.de/studio-franken/aktuelles-aus-franken/jugend-forsch t-robert-schaller-sonderpreis-vde-ID1273673737606.xml?_requestid=146846 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
