Re: OM as car navigation
Am 27.02.2012 22:04, schrieb robin: hi, i still have problems with qtmoko v39 to use navit or tango/foxtrotgps. would you mind to post your gpsd file and the navit.xml line for your gpsd connection? .. robin Hallo robin, here is my solution: file /etc/default/gpsd # Default settings for gpsd. # Please do not edit this file directly - use `dpkg-reconfigure gpsd' to # change the options. START_DAEMON=true GPSD_OPTIONS= DEVICES=/dev/ttySAC1 USBAUTO=true GPSD_SOCKET=/var/run/gpsd.sock vehicle-Tag from file /home/root/.navit/navit.xml: vehicle name=Local GPS profilename=car enabled=yes active=1 source=gpsd://localhost:2947 gpsd_query=w+xj follow=3 Port :2947 is one try of many, must also run without. More on: http://wiki.openmoko.org/wiki/Navit#Center_on_Vehicle and http://wiki.navit-project.org/index.php/Configuring_Navit#The_Vehicles_Definitions -- Frank ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
Hi Frank, Thanks for your answer. 2012/2/27 Frank fr...@fotodrachen.de: Am 27.02.2012 17:21, schrieb Guilhem Bonnefille: I don't really know, what the reason was. I think it was a missing device in the gpsd-configuration. Other GPS-Apps worked well - but not navit. Maybe they use the gps-device without gpsd? I had to run $ dpkg-reconfigure gpsd and set device to /dev/ttySAV1 Is gpsd for gta02 shipped with empty device-entry in .conf? Strange. Did you run gpsd? Last time I played with navit in qtmoko, I realized that qtmoko does not run automatically gpsd. Some packaging work must still be done to manage gpsd when GPS device is switched on/off and when navit is started/stopped. As far as I know, NeronGPS uses raw device directly (does not use gpsd), and directly switch on/off the power for the device. At the opposite, navit is really well packaged in SHR. A simple tap on the navit icon and everithing goes well. Perhaps someone can pick some ideas from SHR to port them to qtmoko. Nevertheless, this is all the reason why I wish to start a dedicated project. A base distribution with just some configuration to: - power up the device at start time - save and restore the A-GPS data - start navit - some choices to optimize rendering on Freerunner (refresh rate, detail level...) -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
Hi, 2012/2/26 Christoph Pulster openm...@pulster.de: please see Openmoko inside a vehicle as navigation system: https://despora.de/posts/228392 Credits go to Frank Jaeger (fr...@fotodrachen.de) ! Software: Navit with routing data from OpenStreetMap. gpsd shows actual position. Hardware: Freerunner with vehicle holder (19 eur in pulster.eu shop). Great, I recently posted in order to discover if someone already did such a job. Personnally, I used navit with qtmoko and SHR. Worked quite good. But as I removed my SIM, I'm now looking for a projet dedicated to converting Freerunner in car navigation system (and nothing more). Do you know what operating system was used by Frank Jaeger? -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
Am 27.02.2012 17:21, schrieb Guilhem Bonnefille: Hi, .. Do you know what operating system was used by Frank Jaeger? Hallo Guilhem, it's a QTmoko v38. I startet with v35 and navit in QX-mode. Now navit can be installed very confortable as App from http://qtmoko.sourceforge.net/apps/category-gps.html using the browser. But navit didn't get the actual gps-position. Also after upgrading to v37 and v39 and several attempts to configure the gpsd-vehicle in /home/root/.navit/navit.xml [1] Finally I formatted my uSD-Card and unpacked a fresh QTmoko v38. But this didn't help me, too. Last weekend I started a new attemp and get navit to work! I was so happy that i postet ist on Despora.de and FB. I don't really know, what the reason was. I think it was a missing device in the gpsd-configuration. Other GPS-Apps worked well - but not navit. Maybe they use the gps-device without gpsd? I had to run $ dpkg-reconfigure gpsd and set device to /dev/ttySAV1 Is gpsd for gta02 shipped with empty device-entry in .conf? [1] https://github.com/radekp/qtmoko/issues/23 -- Frank ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
On 27.02.2012 19:27, Frank wrote: Am 27.02.2012 17:21, schrieb Guilhem Bonnefille: Hi, .. Do you know what operating system was used by Frank Jaeger? Hallo Guilhem, it's a QTmoko v38. I startet with v35 and navit in QX-mode. Now navit can be installed very confortable as App from http://qtmoko.sourceforge.net/apps/category-gps.html using the browser. But navit didn't get the actual gps-position. Also after upgrading to v37 and v39 and several attempts to configure the gpsd-vehicle in /home/root/.navit/navit.xml [1] Finally I formatted my uSD-Card and unpacked a fresh QTmoko v38. But this didn't help me, too. Last weekend I started a new attemp and get navit to work! I was so happy that i postet ist on Despora.de and FB. I don't really know, what the reason was. I think it was a missing device in the gpsd-configuration. Other GPS-Apps worked well - but not navit. Maybe they use the gps-device without gpsd? I had to run $ dpkg-reconfigure gpsd and set device to /dev/ttySAV1 Is gpsd for gta02 shipped with empty device-entry in .conf? [1] https://github.com/radekp/qtmoko/issues/23 Most statements on the blog are totaly wrong! I use my neo with navit since I have purchased my neo last autumn! You have to set the correct device for gpsd once. Then You have to install festival-lite with apt and by configuring navit-config file in home dir of user. that is it! So speech output is working, ok english, so You have to set up the environment variable correct. I did not, because is not so importent for me. Then navit is usable by using the QX-way. Radek's new QX-less version, I have not tested until now. But seems to make it a little bit easier. So install festival, configure navit correct and it will work -- Regaards Sebastian Reinhardt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
hi timo, the display freezes, I don't know if that means that the kernel has crashed. any ideas. best regards robin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
robin spielr...@web.de writes: the display freezes, I don't know if that means that the kernel has crashed. any ideas. Does it reply to ping over wifi or usb when that happens? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
hi, i still have problems with qtmoko v39 to use navit or tango/foxtrotgps. would you mind to post your gpsd file and the navit.xml line for your gpsd connection? I start gps manually via the gps on script beforehand and nerongps gets a nice fix, in contrast to navit :-( best regards robin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
hi timo, unfortunately I can't answer that as that usually happens during driving in my car ... Could I do anything useful to give you more information on that? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
[For people not also following the GTA04 ML: this followup makes (a little) sense following the case manufacturing discussion at http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001691.html, in particular regarding the large hole underneath neo.] openm...@pulster.de (Christoph Pulster) writes: Hi, please see Openmoko inside a vehicle as navigation system: https://despora.de/posts/228392 And there's another unidentified use of the hole there too. I wonder what that string is for? :-) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
On 02/26/2012 10:56 AM, Christoph Pulster wrote: Hi, please see Openmoko inside a vehicle as navigation system: https://despora.de/posts/228392 Credits go to Frank Jaeger (fr...@fotodrachen.de) ! Software: Navit with routing data from OpenStreetMap. gpsd shows actual position. Hardware: Freerunner with vehicle holder (19 eur in pulster.eu shop). Have fun, Chris Hi Chris, Yep, with the right software the FR can indeed be used as navigation system with text-to-speech and all. Have done that for a while with your vehicle holder (I bought it long ago). Ben ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
One of the problems with navit though is that it very much likes to freeze the freerunner completely (battery removal needed :-( ). the best voices so far I found on navit for android on freerunner. so if anyone has any suggestions for good voices for qtmoko or shr those would be most welcome. robin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
Hi Robin, One of the things i do before starting navit is: if test -f ~/.navit/destination.txt; then rm ~/.navit/destination.txt fi if test -f ~/.navit/center.txt; then rm ~/.navit/center.txt fi With that i never have a hanging navit, without it it takes *forever* to start and eat the whole CPU. Kind regards, Ed On 02/26/2012 07:42 PM, robin wrote: One of the problems with navit though is that it very much likes to freeze the freerunner completely (battery removal needed :-( ). the best voices so far I found on navit for android on freerunner. so if anyone has any suggestions for good voices for qtmoko or shr those would be most welcome. robin ___ 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: OM as car navigation
hi ed, i will try that. do you also have a simple hack to check for a minimal number of satelites or even better for a threshold for lateral deviation of the position. this would avoid the other problem causing navit to freeze: if you are right next to a motorway and the satelite signal is not accurate navit will jump inbetween calculating the route starting from the motorway and then again from the little road besides it, which causes extrem cpu usage and eventually makes the freerunner crash within navit one can check for the number of satelites, I don't know if this is also possible in qtmoko or shr. best regards robin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
robin spielr...@web.de writes: then again from the little road besides it, which causes extrem cpu usage and eventually makes the freerunner crash The kernel crashes? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navigation board @ Pulster shop
On Sat, 18 Jun 2011 17:51:33 +0200, Christoph Mair m...@chonyota.net wrote: Am Samstag 18 Juni 2011, 14:51:05 schrieb Daniele Forsi: can someone recommend an USB-i2c interface to use the navigation board externally, for those who don't feel like touching their Freerunner with a soldering iron or have a netbook? The wiki page now contains instructions on how to connect the naviboard v3 to a graphics card [1]. This should enable everyone to use it and requires only three parts: a VGA connector (or DVI or HDMI), a 3V regulator (LDO) and a naviboard. Connect everything as described, plug it in, load the i2c-dev module and run i2cdetect to check if it's working. If the instructions are not detailed enough, please complain and I will try to clarify any issues. I tested this setup with the integrated Intel graphics card on my notebook and it worked fine, a test with an nvidia card will follow. To find the right I2C bus on your machine, load the i2c-dev module and run i2cdetect on all available busses (look in /sys/bus/i2c/devices for i2c-*, or simply try this: for i in `seq 1 20`; do echo $i; i2cdetect -y $i; done;). The commands output should be different if your monitor is disconnected (or switched off). Have fun! Christoph [1]: http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3#Example:_connect_the_board_to_a_graphics_card ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navigation board @ Pulster shop
2011/6/17 Christoph Pulster wrote: I think the Open Source community is missing to link and interaction between projects. Add-on products like navigation-board can cross the gap, for exaple it is useful for Openmoko, Qi Nanonote and Pandora. indeed can someone recommend an USB-i2c interface to use the navigation board externally, for those who don't feel like touching their Freerunner with a soldering iron or have a netbook? -- Daniele Forsi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navigation board @ Pulster shop
Am Samstag 18 Juni 2011, 14:51:05 schrieb Daniele Forsi: 2011/6/17 Christoph Pulster wrote: I think the Open Source community is missing to link and interaction between projects. Add-on products like navigation-board can cross the gap, for exaple it is useful for Openmoko, Qi Nanonote and Pandora. indeed can someone recommend an USB-i2c interface to use the navigation board externally, for those who don't feel like touching their Freerunner with a soldering iron or have a netbook? I don't have experiences with USB-I2C interfaces but anyone should work. Be sure to add a 3V voltage regulator (LDO) if you want to power the board from USB which supplies 5V. If you want you can build your own adapter using an old VGA cable. The I2C bus is used for DDC. If you have a spare VGA or DVI connector on your computer you could use it to connect the FRNB (http://en.wikipedia.org/wiki/VGA_connector pin 12 and pin 15). To power the board you could try pin 9 which should carry 5V. Use a LDO regulator to get 3.3V or 3.0V which is needed for the sensors. The I2C bus needs level translation too. Fortunately, if you have a complete board, the needed chip is already included. I will add a section to the wiki about how to connect the board to a 5V I2C bus. Pinout and more documentation will be added too. Hope that helps, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Video of SMD production of Freerunner Navigation Boards (GTA04 will look similar)
On Thu, Jun 9, 2011 at 16:38, Dr. H. Nikolaus Schaller h...@goldelico.com wrote: Dear all, we were allowed to look over the shoulders of the workers at the SMD fab that produces the Freerunner Navigation Board V3 and the GTA04. Here is the link: http://www.youtube.com/watch?v=ngyhKr3yTO8 It shows how the PCBs are set up, how the pickplace machine is set up and how the components are placed. Finally, it goes through the reflow oven. The video shows the Freerunner Navigation boards which were produced yesterday and are finalized today. They promised to produce the first two GTA04A3 boards today so that we can test them in the next days and week. Since it looks very similar we do without another video. Nikolaus Awesome video, awesome project, and I love the openness you displayed so far. I really hope this becomes a success and can only congratulate to the courage to pull all this of. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Video of SMD production of Freerunner Navigation Boards (GTA04 will look similar)
What happens behind the scene was obscured until now to me.. This video gave an overview of really cool stuff *HAPPENING* . Thank you Rgds On 6/10/11, Thomas Gstädtner tho...@gstaedtner.net wrote: On Thu, Jun 9, 2011 at 16:38, Dr. H. Nikolaus Schaller h...@goldelico.com wrote: Dear all, we were allowed to look over the shoulders of the workers at the SMD fab that produces the Freerunner Navigation Board V3 and the GTA04. Here is the link: http://www.youtube.com/watch?v=ngyhKr3yTO8 It shows how the PCBs are set up, how the pickplace machine is set up and how the components are placed. Finally, it goes through the reflow oven. The video shows the Freerunner Navigation boards which were produced yesterday and are finalized today. They promised to produce the first two GTA04A3 boards today so that we can test them in the next days and week. Since it looks very similar we do without another video. Nikolaus Awesome video, awesome project, and I love the openness you displayed so far. I really hope this becomes a success and can only congratulate to the courage to pull all this of. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Ranjit Pillai gnumen.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Video of SMD production of Freerunner Navigation Boards (GTA04 will look similar)
Dear all, we were allowed to look over the shoulders of the workers at the SMD fab that produces the Freerunner Navigation Board V3 and the GTA04. Here is the link: http://www.youtube.com/watch?v=ngyhKr3yTO8 It shows how the PCBs are set up, how the pickplace machine is set up and how the components are placed. Finally, it goes through the reflow oven. The video shows the Freerunner Navigation boards which were produced yesterday and are finalized today. They promised to produce the first two GTA04A3 boards today so that we can test them in the next days and week. Since it looks very similar we do without another video. Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Video of SMD production of Freerunner Navigation Boards (GTA04 will look similar)
Hi, thats really nice video. Best Regards, Martin Martix Holec 2011/6/9 Dr. H. Nikolaus Schaller h...@goldelico.com: Dear all, we were allowed to look over the shoulders of the workers at the SMD fab that produces the Freerunner Navigation Board V3 and the GTA04. Here is the link: http://www.youtube.com/watch?v=ngyhKr3yTO8 It shows how the PCBs are set up, how the pickplace machine is set up and how the components are placed. Finally, it goes through the reflow oven. The video shows the Freerunner Navigation boards which were produced yesterday and are finalized today. They promised to produce the first two GTA04A3 boards today so that we can test them in the next days and week. Since it looks very similar we do without another video. Nikolaus ___ 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: FreeRunner Navigation Board v3 - Power management
Hi, 2011/5/21 Christoph Mair m...@chonyota.net: Hi, Am Samstag 21 Mai 2011, 16:41:06 schrieb Martix: How much of power Navigation Board v3 consume, both in operational state (all sensors are active) and in idle state (all sensors are powered down)? Can I power down whole board from software? All sensors support a sleep state which reduces power consumption fo a few µA. I will add exact numbers to the wiki page. The sleep state is activated automatically after power-on. Therefore you have to talk to the sensor to activate it. The only exception is the gyroscope ITG-3200. This sensor needs the kernel module which will switch it of immediately after the module was loaded. If you forget to do this, it will consume about 6mA, IIRC. could be board VCC connected somehow to the PMU (PCF50633)? Perhaps, Navigation Board could use free power line from PMU, if it's available or share power line with one accelerometer or GPS. I don't know much about the PMU, but I tried to connect the board to one accelerometers VCC pin. It works, but I would not recommend it, because the I2C lines are pulled up when idle. If the chips do not get powered, some current may flows from the bus lines to ground. This could be more that the normal standby current. But I have to admit that I did not thest this yet. Ok, I understand, current can leak through accerometer to GND. But, this can also happen with VCC connected to AUX, when AUX LED is on. This could be explanation for NOR u-boot problem. http://wiki.openmoko.org/wiki/I2C#Powering_additional_I2C_devices According to http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board#Installation the AUX power is disabled in suspend. Is this PMU behavior configurable from software? For example, if I want to wake up Neo FreeRunner from suspend by IRQ interrupt from Navigation Board. I know about test pins with 0R resitors on PMU power outputs used for external current measurement, VCC could be provided from one of these pads. I'd like to hear more about these 0Rs.. These pins could by used for current measurement (for example replace 0R by 0.1R and measure voltage drop on it) or for powering peripheral devices from external sources. For practical use see: http://ertos.nicta.com.au/publications/papers/Carroll_Heiser_10.pdf Did anybody considered PMU power management approach with Navigation Board? It should not be needed and could even be a bad idea. See above. Fortunately, I've found free PMU power output LDO3OUT alias test pin H-TP1702, which is proper solution for powering expansion devices/board like this. On the other hand its not easily accessible as AUX button or accelerometer, because its located near PMU under EM shielding, but its not impossible to wire it out. (Please, keep this in mind during GTA04 design process and wire at least one 3V3 power line outside shielding.) PS: It would be nice to have some informations regarding power management documented on the wiki: http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3 I will add some more info. The wiki page lacks a few other updates too.. pinout and new pictures, for example.. I will try to fix this tomorrow. Best Regards, Christoph Best Regards, Martix ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeRunner Navigation Board v3 - Power management
Am Sonntag 22 Mai 2011, 11:44:24 schrieben Sie: Hi, 2011/5/21 Christoph Mair m...@chonyota.net: Hi, Am Samstag 21 Mai 2011, 16:41:06 schrieb Martix: How much of power Navigation Board v3 consume, both in operational state (all sensors are active) and in idle state (all sensors are powered down)? Can I power down whole board from software? All sensors support a sleep state which reduces power consumption fo a few µA. I will add exact numbers to the wiki page. The sleep state is activated automatically after power-on. Therefore you have to talk to the sensor to activate it. The only exception is the gyroscope ITG-3200. This sensor needs the kernel module which will switch it of immediately after the module was loaded. If you forget to do this, it will consume about 6mA, IIRC. See http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3#Power_consumption could be board VCC connected somehow to the PMU (PCF50633)? Perhaps, Navigation Board could use free power line from PMU, if it's available or share power line with one accelerometer or GPS. I don't know much about the PMU, but I tried to connect the board to one accelerometers VCC pin. It works, but I would not recommend it, because the I2C lines are pulled up when idle. If the chips do not get powered, some current may flows from the bus lines to ground. This could be more that the normal standby current. But I have to admit that I did not thest this yet. Ok, I understand, current can leak through accerometer to GND. But, this can also happen with VCC connected to AUX, when AUX LED is on. This could be explanation for NOR u-boot problem. http://wiki.openmoko.org/wiki/I2C#Powering_additional_I2C_devices I mostly use power from the AUX switch. With the FRNBv3 I did not encounter the NOR u-boot problem yet. Everything seems to work fine. If someone encounters a problem, there are solderpads for additional capacitors on the bottom side to fix evantual issues. According to http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board#Installation the AUX power is disabled in suspend. Is this PMU behavior configurable from software? For example, if I want to wake up Neo FreeRunner from suspend by IRQ interrupt from Navigation Board. You got that wrong. The AUX power is always available, just the power to the accelorometers is shut down in suspend. If you grab your VCC from the decoupling cap of the accel, all sensors will be switched off. If you want to weak the FR using a IRQ triggered from the FRNB, you need an additional wire to connect one sensor to a IRQ line on the FR. Since v3, all interrupt outputs of the sensors are available on (tiny) testpoints. Fortunately, I've found free PMU power output LDO3OUT alias test pin H-TP1702, which is proper solution for powering expansion devices/board like this. On the other hand its not easily accessible as AUX button or accelerometer, because its located near PMU under EM shielding, but its not impossible to wire it out. I did not try this yet. (Please, keep this in mind during GTA04 design process and wire at least one 3V3 power line outside shielding.) Depending on measurement results, we may do not need a shield and there are testpoints which you can use to power additional electronics. PS: It would be nice to have some informations regarding power management documented on the wiki: http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3 I will add more information when I can test the first machine assembled board. Best regards, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
FreeRunner Navigation Board v3 - Power management
Hello, How much of power Navigation Board v3 consume, both in operational state (all sensors are active) and in idle state (all sensors are powered down)? Can I power down whole board from software? If not, could be board VCC connected somehow to the PMU (PCF50633)? Perhaps, Navigation Board could use free power line from PMU, if it's available or share power line with one accelerometer or GPS. I know about test pins with 0R resitors on PMU power outputs used for external current measurement, VCC could be provided from one of these pads. Did anybody considered PMU power management approach with Navigation Board? I like to hear your opinion and suggestions about this matter. PS: It would be nice to have some informations regarding power management documented on the wiki: http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3 Best Regards, Martix ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeRunner Navigation Board v3 - Power management
Hi, Am Samstag 21 Mai 2011, 16:41:06 schrieb Martix: How much of power Navigation Board v3 consume, both in operational state (all sensors are active) and in idle state (all sensors are powered down)? Can I power down whole board from software? All sensors support a sleep state which reduces power consumption fo a few µA. I will add exact numbers to the wiki page. The sleep state is activated automatically after power-on. Therefore you have to talk to the sensor to activate it. The only exception is the gyroscope ITG-3200. This sensor needs the kernel module which will switch it of immediately after the module was loaded. If you forget to do this, it will consume about 6mA, IIRC. could be board VCC connected somehow to the PMU (PCF50633)? Perhaps, Navigation Board could use free power line from PMU, if it's available or share power line with one accelerometer or GPS. I don't know much about the PMU, but I tried to connect the board to one accelerometers VCC pin. It works, but I would not recommend it, because the I2C lines are pulled up when idle. If the chips do not get powered, some current may flows from the bus lines to ground. This could be more that the normal standby current. But I have to admit that I did not thest this yet. I know about test pins with 0R resitors on PMU power outputs used for external current measurement, VCC could be provided from one of these pads. I'd like to hear more about these 0Rs.. Did anybody considered PMU power management approach with Navigation Board? It should not be needed and could even be a bad idea. See above. PS: It would be nice to have some informations regarding power management documented on the wiki: http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3 I will add some more info. The wiki page lacks a few other updates too.. pinout and new pictures, for example.. I will try to fix this tomorrow. Best Regards, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ANN: Freerunner Navigation Board v3 (FRNBv3)
[cut] I hope you find this little device useful for your projects. If there are any questions, please let me know. Nice... If you keep up pace like this, you will soon produce new open phone :) -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ANN: Freerunner Navigation Board v3 (FRNBv3)
Hello Christoph, On Tue, Apr 12, 2011 at 21:12, Christoph Mair m...@chonyota.net wrote: I already announced it (http://lists.openmoko.org/pipermail/community/2011- February/064474.html), now I'm ready to start production: The Freerunner Navigation Board v3 is finished! Looks very nice indeed! Will it be possible to order a GTA04 upgrade with a navigation board included in the re-work? Christ van Willegen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ANN: Freerunner Navigation Board v3 (FRNBv3)
Dear List, I already announced it (http://lists.openmoko.org/pipermail/community/2011- February/064474.html), now I'm ready to start production: The Freerunner Navigation Board v3 is finished! It features a compass, a gyroscope and an accelerometer. All of them work in three dimensions. Together with the included pressure sensor you get a 10 degrees of freedom sensor board which should be usable for inertial navigation, as flight controller or recorder for drones such as quadrocopters and possibly a lot of other gadgets. To be compatible with as many embedded boards as possible, the supply voltage and the I/O voltage of the I²C bus can be different. A 3V - 3.6V supply voltage (VCC) is recommended for the sensors, while the I/O voltage can be anything between 1.8V and VCC. This feature enables connectivity to your Freerunner as well as to most other embedded devices such as the OpenPandora (there is enough space inside the case) or devices from Always Innovating. If you want even more functionality: the bottom side contains: - the MPR121 touch sensor controller - a 38kHz fixed frequency oscillator for IR remote control applications - the TCA6507 7 channel LED controller - a I2C level shifter to connect even more sensors with different I/O voltages - a I²C EEPROM which is also accessible through 13.45MHz RFID. Preliminary documentation is available on the wiki page http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3 It will be improved within the next two weeks. Schematic and PCB-Layout are available from https://gitorious.org/frnbv3/frnbv3-hardware (Cadsoft Eagle file format) Preorders can be placed on http://www.handheld- linux.com/wiki.php?page=Navigation%20Board General availability is scheduled for mid-may. I hope you find this little device useful for your projects. If there are any questions, please let me know. Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ANN: Freerunner Navigation Board v2 is finally available
Dear list, we have received and tested the next handful of navigation boards. They are available through: http://www.handheld-linux.com/wiki.php?page=Navigation%20Board For installation, please refer to http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2#Installation and http://chonyota.net/freerunner/FRNBv2/FRNBv2-Installation.pdf Nikolaus Am 12.09.2010 um 20:24 schrieb Christoph Mair: Dear list, after lots of hard work I'm happy to announce that the Freerunner Navigation Board v2 is finally available! The team from handheld-linux.com [1] kindly offered to handle orders and shipping. The second version of the Navigation Board includes some features which go well beyond of what is needed for navigational purposes. The board comes in two assembly variants standard and complete. See below for a feature description/comparison. The most recent documentation as well as possible use cases and bug descriptions can always be found on the wiki page [2]. Features supported by any board: * 3D magnetometer The magnetometer measures magnetic forces on three axes. With some math it can be used as a compass. Alternatively, use it to measure the magnetic fields generated by trains while accelerating (e.g. underground lines). * 3D gyroscope A gyroscope measures angular velocity. It can determine how fast you spin your Freerunner around its three axes. Usable to support the integrated accelerometers for inertial navigation (navigation without GPS) or to create a wireless game controller (like the wii). * Barometric pressure sensor The change in ambient air pressure is a good indicator for changing weather conditions. If the weather is relatively stable and the barometric pressure changes, it usually indicates that the height above sea level changed. If this value is known the absolute height can be calculated without using the GPS. * Four channel LED controller This LED controller can dim and make blink up to four LEDs (e.g. RGBA). It works autonomously, even if the main CPU is suspended. This may for instance be used to indicate unread messages. Large blinking intervals and duty cycles enable short flashes to save battery power. Alternatively one could connect a high brightness LED and use the Freerunner as a dimmable torch. * Seven channel touch controller The chip could actually control twelve channels, but due to space restrictions only seven are available on the FRNBv2. They can be used to add touch buttons to your Freerunner or act as proximity detector. E.g.: disable the screen lock if you pick up the phone. (*) Four channels can also drive LEDs, if you don't need them for something else. Additional features of the complete boards: * 12-Bit analog to digital converter This chip is very similar to the one used on the Freerunner Navigation Board v1 to digitize the output of the gyroscopes. The FRNBv2 does not use it for own purposes, it's completely under users' control. A possible use cases would be an ambient light sensor. Or use it to measure the current consumption of the FRNBv2 ;-) * Programmable oscillator Do you need to generate a rectangular signal with programmable frequency between 1kHz and 68MHz? Then this chip is made for you. What can you use it for? I thought about a 38kHz oscillator which can be enabled and disabled using a GPIO pin. This could be used as generic infrared remote control. If you really need these two last features, order a complete board or add the chips yourself to any standard board. They come in leaded packages and are hand solderable if you have some soldering experience. (*) This feature was not tested yet due to a missing kernel driver. I'm not sure if it will work as expected. (**) The programmable oscillator does not work due to a strange bug. See the wiki [2] for details. Have fun! Christoph [1] http://www.handheld-linux.com/wiki.php?page=Navigation%20Board [2] http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2 ___ 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
Freerunner Navigation Board
We have received and tested the next batch of Freerunner navigation boards. The test was done by using a Letux 400 where we did solder 4 cables to get an external I2C bus and some spring contacts. More details can be found at: http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2 And, please report your ideas, results, software, fun, etc. here! Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ANN: Freerunner Navigation Board v2 is finally available
Looks good. It'll be a month or so before I can order one. On Sunday 12 September 2010, Christoph Mair wrote: Dear list, after lots of hard work I'm happy to announce that the Freerunner Navigation Board v2 is finally available! The team from handheld-linux.com [1] kindly offered to handle orders and shipping. The second version of the Navigation Board includes some features which go well beyond of what is needed for navigational purposes. The board comes in two assembly variants standard and complete. See below for a feature description/comparison. The most recent documentation as well as possible use cases and bug descriptions can always be found on the wiki page [2]. Features supported by any board: * 3D magnetometer The magnetometer measures magnetic forces on three axes. With some math it can be used as a compass. Alternatively, use it to measure the magnetic fields generated by trains while accelerating (e.g. underground lines). * 3D gyroscope A gyroscope measures angular velocity. It can determine how fast you spin your Freerunner around its three axes. Usable to support the integrated accelerometers for inertial navigation (navigation without GPS) or to create a wireless game controller (like the wii). * Barometric pressure sensor The change in ambient air pressure is a good indicator for changing weather conditions. If the weather is relatively stable and the barometric pressure changes, it usually indicates that the height above sea level changed. If this value is known the absolute height can be calculated without using the GPS. * Four channel LED controller This LED controller can dim and make blink up to four LEDs (e.g. RGBA). It works autonomously, even if the main CPU is suspended. This may for instance be used to indicate unread messages. Large blinking intervals and duty cycles enable short flashes to save battery power. Alternatively one could connect a high brightness LED and use the Freerunner as a dimmable torch. * Seven channel touch controller The chip could actually control twelve channels, but due to space restrictions only seven are available on the FRNBv2. They can be used to add touch buttons to your Freerunner or act as proximity detector. E.g.: disable the screen lock if you pick up the phone. (*) Four channels can also drive LEDs, if you don't need them for something else. Additional features of the complete boards: * 12-Bit analog to digital converter This chip is very similar to the one used on the Freerunner Navigation Board v1 to digitize the output of the gyroscopes. The FRNBv2 does not use it for own purposes, it's completely under users' control. A possible use cases would be an ambient light sensor. Or use it to measure the current consumption of the FRNBv2 ;-) * Programmable oscillator Do you need to generate a rectangular signal with programmable frequency between 1kHz and 68MHz? Then this chip is made for you. What can you use it for? I thought about a 38kHz oscillator which can be enabled and disabled using a GPIO pin. This could be used as generic infrared remote control. If you really need these two last features, order a complete board or add the chips yourself to any standard board. They come in leaded packages and are hand solderable if you have some soldering experience. (*) This feature was not tested yet due to a missing kernel driver. I'm not sure if it will work as expected. (**) The programmable oscillator does not work due to a strange bug. See the wiki [2] for details. Have fun! Christoph [1] http://www.handheld-linux.com/wiki.php?page=Navigation%20Board [2] http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2 ___ 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: ANN: Freerunner Navigation Board v2 is finally available
Am Montag 13 September 2010, 01:14:43 schrieb jeremy jozwik: indeed, is there any software in the works to take advantage of this? i think i might have to snag one and add it on when i tear open my phone to fix the sd card... Kernel drivers for most chips are available from [1]. Each sensor (except the touch/proximity sensor) is supported by the sensor-monitor application [2]. Better overall integration is planned. Mickey agreed to add dbus interfaces to FSO. I am trying to get the drivers merged into official kernel repositories, but most of them lack documentation and proper error handling. I will try to get these drivers merged into the SHR and/or QtMoko kernel repositories, but I'll have to find out if the maintainers would accept these beta-drivers until I get them ready for kernel.org. Meanwhile you have to compile them yourself or bug me to do it for you (should not be a problem, except that I have to do it again when the kernel version string changes). Other software that is available or planned: * Compass (HMC5843): A kernel driver (not mine) was merged upstream (into staging/iio) a few weeks ago. It should be rather easy to enhance fso-gpsd to use magnetic measurements. * Gyroscope (ITG-3200): There is no software support that I'm aware of. I will try to implement an inertial navigation solution but you are probably faster if you try yourself instead of waiting for mine. * Pressure sensor (BMP085): My kernel driver was merged upstream. There are no other userspace applications available till now. * LED controller: The kernel driver was initially written for the GTA03 (found it somewhere on the internet). I did not push it to my repository yet but I will do it during this week. Maybe the FSO team adds support for this.. * A/D: Missing userspace applications (except the sensor monitor) * Oscillator: Still buggy. If I can fix the bug I will implement a LIRC driver to use it as a remote control. Of course, the lack of applications means that you should do something to improve the situation! Either add new Ideas to the wiki page or start hacking on something ;-) Christoph [1] http://gitorious.org/freerunner-navigation-board [2] http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board#End_user_software ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ANN: Freerunner Navigation Board v2 is finally available
Dear list, after lots of hard work I'm happy to announce that the Freerunner Navigation Board v2 is finally available! The team from handheld-linux.com [1] kindly offered to handle orders and shipping. The second version of the Navigation Board includes some features which go well beyond of what is needed for navigational purposes. The board comes in two assembly variants standard and complete. See below for a feature description/comparison. The most recent documentation as well as possible use cases and bug descriptions can always be found on the wiki page [2]. Features supported by any board: * 3D magnetometer The magnetometer measures magnetic forces on three axes. With some math it can be used as a compass. Alternatively, use it to measure the magnetic fields generated by trains while accelerating (e.g. underground lines). * 3D gyroscope A gyroscope measures angular velocity. It can determine how fast you spin your Freerunner around its three axes. Usable to support the integrated accelerometers for inertial navigation (navigation without GPS) or to create a wireless game controller (like the wii). * Barometric pressure sensor The change in ambient air pressure is a good indicator for changing weather conditions. If the weather is relatively stable and the barometric pressure changes, it usually indicates that the height above sea level changed. If this value is known the absolute height can be calculated without using the GPS. * Four channel LED controller This LED controller can dim and make blink up to four LEDs (e.g. RGBA). It works autonomously, even if the main CPU is suspended. This may for instance be used to indicate unread messages. Large blinking intervals and duty cycles enable short flashes to save battery power. Alternatively one could connect a high brightness LED and use the Freerunner as a dimmable torch. * Seven channel touch controller The chip could actually control twelve channels, but due to space restrictions only seven are available on the FRNBv2. They can be used to add touch buttons to your Freerunner or act as proximity detector. E.g.: disable the screen lock if you pick up the phone. (*) Four channels can also drive LEDs, if you don't need them for something else. Additional features of the complete boards: * 12-Bit analog to digital converter This chip is very similar to the one used on the Freerunner Navigation Board v1 to digitize the output of the gyroscopes. The FRNBv2 does not use it for own purposes, it's completely under users' control. A possible use cases would be an ambient light sensor. Or use it to measure the current consumption of the FRNBv2 ;-) * Programmable oscillator Do you need to generate a rectangular signal with programmable frequency between 1kHz and 68MHz? Then this chip is made for you. What can you use it for? I thought about a 38kHz oscillator which can be enabled and disabled using a GPIO pin. This could be used as generic infrared remote control. If you really need these two last features, order a complete board or add the chips yourself to any standard board. They come in leaded packages and are hand solderable if you have some soldering experience. (*) This feature was not tested yet due to a missing kernel driver. I'm not sure if it will work as expected. (**) The programmable oscillator does not work due to a strange bug. See the wiki [2] for details. Have fun! Christoph [1] http://www.handheld-linux.com/wiki.php?page=Navigation%20Board [2] http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ANN: Freerunner Navigation Board v2 is finally available
--- On Sun, 9/12/10, Christoph Mair m...@chonyota.net wrote: after lots of hard work I'm happy to announce that the Freerunner Navigation Board v2 is finally available! It looks great, congratulations! Boudewijn ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ANN: Freerunner Navigation Board v2 is finally available
On Sun, Sep 12, 2010 at 1:23 PM, W. B. Kranendonk wankelwan...@yahoo.com wrote: It looks great, congratulations! indeed, is there any software in the works to take advantage of this? i think i might have to snag one and add it on when i tear open my phone to fix the sd card... ___ 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
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: 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
Re: ANN: Freerunner Navigation Board v2
How about an altitude (pressure) sensor? That would make up for the accuracy of GPS height data. Tim Abell Christoph Mair wrote: Hi all! Thanks to a new triaxial gyroscope chip which became available a few weeks ago I started to work on a new navigation board for the freerunner. The new chip reduces the complexity which results in a single layer board containing the triaxial gyroscope ITG3200, the triaxial compass HMC5843, and the pressure sensor BMP085 and about seven passive components. The layout is done a final test is still pending. All drivers are tested and they work. Currently I'm waiting for a quote about how much it would cost to assemble the boards. It should be possible to get the assembled boards including all costs for components, PCB and assembling for about 75€ to 80€. If there is enough interest I'll try to get a first production run done. Since the backside of the board is still empty, the new navigation board won't replace the same amount of embedded air as the first version did. Any ideas on how to fix this 'design flaw'? I'm proposing the SHT21 a digital humidity sensor (from which I have a working sample) but the general availability is still limited. The price difference between a single and a dual layer board is negligible, therefore it's possible to include at least a footprint for new hardware, or simply a lot of solder pads for easier expansion. Suggestions? Cheers, 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: ANN: Freerunner Navigation Board v2
Hi Tim, Am Sonntag 20 Juni 2010, 18:52:06 schrieb Tim Abell: How about an altitude (pressure) sensor? That would make up for the accuracy of GPS height data. As I wrote below, the pressure sensor BMP085 from Bosch Sensortec is already included. This was one goal of the redesign. Christoph Christoph Mair wrote: Hi all! Thanks to a new triaxial gyroscope chip which became available a few weeks ago I started to work on a new navigation board for the freerunner. The new chip reduces the complexity which results in a single layer board containing the triaxial gyroscope ITG3200, the triaxial compass HMC5843, and the pressure sensor BMP085 and about seven passive components. The layout is done a final test is still pending. All drivers are tested and they work. Currently I'm waiting for a quote about how much it would cost to assemble the boards. It should be possible to get the assembled boards including all costs for components, PCB and assembling for about 75€ to 80€. If there is enough interest I'll try to get a first production run done. Since the backside of the board is still empty, the new navigation board won't replace the same amount of embedded air as the first version did. Any ideas on how to fix this 'design flaw'? I'm proposing the SHT21 a digital humidity sensor (from which I have a working sample) but the general availability is still limited. The price difference between a single and a dual layer board is negligible, therefore it's possible to include at least a footprint for new hardware, or simply a lot of solder pads for easier expansion. Suggestions? Cheers, 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ANN: Freerunner Navigation Board v2
Hi all! Thanks to a new triaxial gyroscope chip which became available a few weeks ago I started to work on a new navigation board for the freerunner. The new chip reduces the complexity which results in a single layer board containing the triaxial gyroscope ITG3200, the triaxial compass HMC5843, and the pressure sensor BMP085 and about seven passive components. The layout is done a final test is still pending. All drivers are tested and they work. Currently I'm waiting for a quote about how much it would cost to assemble the boards. It should be possible to get the assembled boards including all costs for components, PCB and assembling for about 75€ to 80€. If there is enough interest I'll try to get a first production run done. Since the backside of the board is still empty, the new navigation board won't replace the same amount of embedded air as the first version did. Any ideas on how to fix this 'design flaw'? I'm proposing the SHT21 a digital humidity sensor (from which I have a working sample) but the general availability is still limited. The price difference between a single and a dual layer board is negligible, therefore it's possible to include at least a footprint for new hardware, or simply a lot of solder pads for easier expansion. Suggestions? Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ANN: Freerunner Navigation Board v2
On Wednesday 16 June 2010, Christoph Mair wrote: Hi all! Thanks to a new triaxial gyroscope chip which became available a few weeks ago I started to work on a new navigation board for the freerunner. The new chip reduces the complexity which results in a single layer board containing the triaxial gyroscope ITG3200, the triaxial compass HMC5843, and the pressure sensor BMP085 and about seven passive components. Nice. I had been looking at the L3G4200D with similar things in mind, but it's not available yet. Perhaps I should have asked about samples. The layout is done a final test is still pending. All drivers are tested and they work. Currently I'm waiting for a quote about how much it would cost to assemble the boards. It should be possible to get the assembled boards including all costs for components, PCB and assembling for about 75€ to 80€. If there is enough interest I'll try to get a first production run done. Since the backside of the board is still empty, the new navigation board won't replace the same amount of embedded air as the first version did. Any ideas on how to fix this 'design flaw'? I'm proposing the SHT21 a digital humidity sensor (from which I have a working sample) but the general availability is still limited. The price difference between a single and a dual layer board is negligible, therefore it's possible to include at least a footprint for new hardware, or simply a lot of solder pads for easier expansion. Suggestions? You had the option of an ambient light sensor using the spare adc channel on the first board. That sensor would still be useful. An ear proximity sensor might be handy. A capacitive sensing element using conductive paint on the inside of the case might do the job. Come to think of it, with a multichannel sensor ic we could use the sides of the case as a slider or a chording keyboard. An ANT transceiver might be nice, but I don't think they're small enough for that space. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Monday 03 May 2010 11:10:40 Jeffrey Ratcliffe wrote: On 3 May 2010 11:04, Dr. H. Nikolaus Schaller h...@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? I don't know exactly how all these programms get their gps data so the following is just a wild guess, but I think it should be rather easy to integrate them into (fso-)gpsd if a inertial navigation system has been developed. Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Christoph Mair wrote: Dear community, we are proud to release a hardware extension for our beloved Freerunner: a navigation board! What is it? The Freerunner Navigation Board is a small PCB which is able to measure rotations as well as the magnetic field in 3D respectively (i.e. compass and gyroscopes integrated). The navigation board can be integrated in the existing Freerunner case. Will the magnetic sensing work with any orientation of the FR? One use for this is to help the GPS in difficult places. The FR is usually placed with the GPS antenna facing up. When the gps signal is good, this can be used to calibrate intertial eqipment. (I.e. automatically figure out what orientation the FR has with respect to the vehicle, how much the vehicle magnetic field distorts the earths field, and how much the local magnetic field deviates from true north.) 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. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: little question about navigation board
Alfa21 wrote: 2010-05...@23:31 Christoph Mair why to add two more gyroscope sensors (so now we have 4 of them in our FR O_O) The Freerunner has two accelerometers, but no gyroscope. I tough 2 accels + 1 compas could act as gyros... (not the greek similar of the kebab) maybe I have to reopen my physic books ^_^' Partially so. A compass only gives you *some* of the direction. Particularly, the compass won't notice if the device spins around the north-south axis. Do it slowly, and the accelerometers may be too limited to notice. Of course, such a movement doesn't normally happen in a car. But you do want to notice if this happens to your plane . . . Helge hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
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. That would be crazily cool! Having 3D parking house data in OSM... So your car never gets lost again :) Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On 3 May 2010 11:04, Dr. H. Nikolaus Schaller h...@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? Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On 5/3/10, Helge Hafting helge.haft...@hist.no wrote: Christoph Mair wrote: Dear community, we are proud to release a hardware extension for our beloved Freerunner: a navigation board! What is it? The Freerunner Navigation Board is a small PCB which is able to measure rotations as well as the magnetic field in 3D respectively (i.e. compass and gyroscopes integrated). The navigation board can be integrated in the existing Freerunner case. Will the magnetic sensing work with any orientation of the FR? Yes it is 3D. One use for this is to help the GPS in difficult places. The FR is usually placed with the GPS antenna facing up. When the gps signal is good, this can be used to calibrate intertial eqipment. (I.e. automatically figure out what orientation the FR has with respect to the vehicle, how much the vehicle magnetic field distorts the earths field, and how much the local magnetic field deviates from true north.) 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. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On 5/2/10, Michael 'Mickey' Lauer mic...@vanille-media.de wrote: Congrats! Will I get a fully assembled one for free if I promise to implement FSO DBus APIs? :) Hey Mickey! In fact we planned to ship you one :) So the next one we will produce is yours. We should keep in touch regarding shipping information and later the API. Cheers Michele ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Am Sonntag, den 02.05.2010, 13:54 +0200 schrieb Michele Brocco: On 5/2/10, Michael 'Mickey' Lauer mic...@vanille-media.de wrote: Congrats! Will I get a fully assembled one for free if I promise to implement FSO DBus APIs? :) Hey Mickey! In fact we planned to ship you one :) So the next one we will produce is yours. We should keep in touch regarding shipping information and later the API. Cheers Michele Splendid! Thanks :) Cheers, Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Christoph Mair escribió: Dear community, we are proud to release a hardware extension for our beloved Freerunner: a navigation board! That's amazing! Great work! would you mind to share why did you developed it? I know it will help and will be used by several project, but what's yours? As you also developed this http://wiki.openmoko.org/wiki/I2C_Pressure_Sensor I certanly think the Neo is going somewhere in the outer space :p Cheers! Kosa - Un mundo mejor es posible - ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Am 02.05.2010 um 16:09 schrieb Kosa: Christoph Mair escribió: Dear community, we are proud to release a hardware extension for our beloved Freerunner: a navigation board! That's amazing! Great work! would you mind to share why did you developed it? I know it will help and will be used by several project, but what's yours? As you also developed this http://wiki.openmoko.org/wiki/I2C_Pressure_Sensor I certanly think the Neo is going somewhere in the outer space :p Good idea! free running into space. Talking to aliens certainly needs open source hard- and software since they have to understand the protocols first :) But seriously, one Freerunner did go to (inner) space on a research rocket (altitude was approx. 100 km): http://freeyourphone.de/portal_v1/viewtopic.php?f=20t=1430p=14569hilit=dlr#p14569 I don't know exactly why Christoph Michele developed this, but I can imagine some areas (who finds other ones?) what that these sensors could be used for. You develop new user interfaces (3D gaming :) and generally improve portable navigation. For car navigation, GPS is in most cases sufficient since a car goes fast enough so that GPS can tell about the direction of movement. But if you have a handheld device, only a compass and/or gyroscope can tell that you are rotating the device. While the LIS302 accelerometers can detect that you shake the device. This gives several new inputs for gesture recognition. The arena is open for creativity... And, I think one can use the pressure sensor either as a weather station (during hiking or skiing) - or to get the altitude and detect ascent/descent better than with GPS. I think all these fine things can augment and integrate with the GPS system. Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Sunday 02 May 2010 17:06:55 Dr. H. Nikolaus Schaller wrote: But seriously, one Freerunner did go to (inner) space on a research rocket (altitude was approx. 100 km): http://freeyourphone.de/portal_v1/viewtopic.php?f=20t=1430p=14569hilit=d lr#p14569 And a second Freerunner will follow: http://www.mail-archive.com/openmoko- ker...@lists.openmoko.org/msg10526.html I don't know exactly why Christoph Michele developed this, but I can imagine some areas (who finds other ones?) what that these sensors could be used for. You develop new user interfaces (3D gaming :) and generally improve portable navigation. For car navigation, GPS is in most cases sufficient since a car goes fast enough so that GPS can tell about the direction of movement. But if you have a handheld device, only a compass and/or gyroscope can tell that you are rotating the device. While the LIS302 accelerometers can detect that you shake the device. This gives several new inputs for gesture recognition. The arena is open for creativity... In fact, inertial navigation was my primary goal. I'd like to use the freerunner to find the right exits within the much underground lines :) Michele wants to do some research on how context aware applications could work on top of this. In general we are very interested to see what the community will do with it. And, I think one can use the pressure sensor either as a weather station (during hiking or skiing) - or to get the altitude and detect ascent/descent better than with GPS. I think all these fine things can augment and integrate with the GPS system. The pressure sensor was a quick relax from other developments project. I like playing with new hardware and this device was rather easy to integrate, but as for now it is a nice addon for the navigation board. Unfortunately the NOR bootloader does not work when both, pressure sensor and navigation board, are connected (somebody knows why?). :) Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Hello. On Sun, 2010-05-02 at 17:42, Christoph Mair wrote: On Sunday 02 May 2010 17:06:55 Dr. H. Nikolaus Schaller wrote: But seriously, one Freerunner did go to (inner) space on a research rocket (altitude was approx. 100 km): http://freeyourphone.de/portal_v1/viewtopic.php?f=20t=1430p=14569hilit=d lr#p14569 And a second Freerunner will follow: http://www.mail-archive.com/openmoko- ker...@lists.openmoko.org/msg10526.html It is actually the same device. :) It just got a nice space-suit and a board with sensors to play with during the trip. ;) http://www.datenfreihafen.org/~stefan/weblog/archives/2010/02/index.html#e2010-02-28T15_40_36.txt http://www.datenfreihafen.org/~stefan/weblog/archives/2010/04/index.html#e2010-04-26T12_30_18.txt Unfortunately the NOR bootloader does not work when both, pressure sensor and navigation board, are connected (somebody knows why?). :) Wild guess. You are not (ab-)using the H-TP4711 testpad which is pin 32 on the debug connector? That one is the write protect disable pin for the NOR. regards Stefan Schmidt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Sunday 02 May 2010 17:57:49 Stefan Schmidt wrote: Hello. On Sun, 2010-05-02 at 17:42, Christoph Mair wrote: Unfortunately the NOR bootloader does not work when both, pressure sensor and navigation board, are connected (somebody knows why?). :) Wild guess. You are not (ab-)using the H-TP4711 testpad which is pin 32 on the debug connector? That one is the write protect disable pin for the NOR. No, during my tests I just connected both devices to the aux-switch (for power) and to to the I2C bus. Then the NOR u-boot did not start when I pressed the aux key (at least it did not enable the display). Disconnecting one of the bus lines (SCL or SDA) or the power supply fixed the problem. I guess this may be because NOR u-boot uses a slower frequency than the linux kernel, but I can't come up with a meaningful expanation for this. I even increased the bus capacitance for one line by adding a 400pF capacitor between SCL and GND. Normally this is the stupiest thing to do, but it fixed the NOR u-boot with the tradeoff that Linux did not boot. :P The wiki mentions possible problems (http://wiki.openmoko.org/wiki/I2C#Powering_additional_I2C_devices), but excludes the NOR u-boot. Best regards, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
little question about navigation board
hi, first of all, congrats for your work :) now my question: why to add two more gyroscope sensors (so now we have 4 of them in our FR O_O) and not just merge a compass to the pressure sensor seen on the wiki (and it has also temperature)? I'm not informed on this topic, so I'm sorry if this question looks stupid :P kind regards -- ALFA21 IS PROVIDED AS IS AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: little question about navigation board
On Sun, May 2, 2010 at 9:57 PM, Alfa21 freerun...@my.is.it wrote: hi, first of all, congrats for your work :) now my question: why to add two more gyroscope sensors (so now we have 4 of them in our FR O_O) and not just merge a compass to the pressure sensor seen on the wiki (and it has also temperature)? Freerunner have only two 3g accelerometers, no gyros. I'm not informed on this topic, so I'm sorry if this question looks stupid :P -- So long, and thanks for all the fish. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Christoph Mair wrote: Soldering experience is definitively required. The QFN chips (gyros and compass) are somewhat difficult to handle, but you can reflow-solder them in a pizza oven. An approach I found quite efficient for occasional DIY of QFN parts on home-made PCBs is to apply a generous amount of flux to the PCB's pads, coat them all with a thin layer of solder, clean up with alcohol, add flux again, place the component, then solder the component's pads one by one while tipping a tiny amount of solder on the traces leading to them. The solder under the pad will liquify and help to make contact. It's not perfect, so you still get all the joy of testing. But it doesn't require anything but the most basic SMT-capable setup, i.e., a soldering iron with a fine tip, solder, flux, and a good desoldering braid. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: little question about navigation board
On Sunday 02 May 2010 19:57:02 Alfa21 wrote: hi, first of all, congrats for your work :) now my question: why to add two more gyroscope sensors (so now we have 4 of them in our FR O_O) The Freerunner has two accelerometers, but no gyroscope. and not just merge a compass to the pressure sensor seen on the wiki I'll think about it. (and it has also temperature)? The pressur sensor needs to measure the ambient temperature to deliver accurate results. The temperature sensor is integrated and can be read using my driver. Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: little question about navigation board
2010-05...@23:31 Christoph Mair why to add two more gyroscope sensors (so now we have 4 of them in our FR O_O) The Freerunner has two accelerometers, but no gyroscope. I tough 2 accels + 1 compas could act as gyros... (not the greek similar of the kebab) maybe I have to reopen my physic books ^_^' -- ALFA21 IS PROVIDED AS IS AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Introducing the Freerunner Navigation Board
Dear community, we are proud to release a hardware extension for our beloved Freerunner: a navigation board! What is it? The Freerunner Navigation Board is a small PCB which is able to measure rotations as well as the magnetic field in 3D respectively (i.e. compass and gyroscopes integrated). The navigation board can be integrated in the existing Freerunner case. How can we test it? In order to test the functionality of the sensors we developed a monitor application for sensors written completely in Vala. For more detailed information on both, Freerunner Navigation Board and Sensor Monitor, please refer to http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board What can we do with it? No idea. Perhaps someone of you can find an appropriate use :p We are looking forward to get feedback and comments. Cheers, Christoph Michele ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Sat, May 1, 2010 at 13:48, Christoph Mair m...@chonyota.net wrote: Dear community, we are proud to release a hardware extension for our beloved Freerunner: a navigation board! What is it? The Freerunner Navigation Board is a small PCB which is able to measure rotations as well as the magnetic field in 3D respectively (i.e. compass and gyroscopes integrated). The navigation board can be integrated in the existing Freerunner case. How can we test it? In order to test the functionality of the sensors we developed a monitor application for sensors written completely in Vala. For more detailed information on both, Freerunner Navigation Board and Sensor Monitor, please refer to http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board What can we do with it? No idea. Perhaps someone of you can find an appropriate use :p We are looking forward to get feedback and comments. Cheers, Christoph Michele Great! Could you write mail about it on shr-devel list with all needed information about drivers? I would like to see drivers for it included by default in SHR :) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Sat, 1 May 2010 13:48:58 +0200 Christoph Mair m...@chonyota.net wrote: Dear community, we are proud to release a hardware extension for our beloved Freerunner: a navigation board! What is it? The Freerunner Navigation Board is a small PCB which is able to measure rotations as well as the magnetic field in 3D respectively (i.e. compass and gyroscopes integrated). The navigation board can be integrated in the existing Freerunner case. How can we test it? In order to test the functionality of the sensors we developed a monitor application for sensors written completely in Vala. For more detailed information on both, Freerunner Navigation Board and Sensor Monitor, please refer to http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board What can we do with it? No idea. Perhaps someone of you can find an appropriate use :p We are looking forward to get feedback and comments. Cheers, Christoph Michele Great work! Are you going to distribute it? If yes, what's the price of one? If no, what's the cost of the modules needed to assemble one (pardon me if this question is stupid)? Cheers, rhn ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Christoph Mair wrote: we are proud to release a hardware extension for our beloved Freerunner: a navigation board! Very impressive. Congratulations ! I guess the next level would be to make a board that fits into one of the Embedded Air (tm) pockets also have some RF transceiver ;-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Saturday 01 May 2010 16:09:05 Werner Almesberger wrote: Christoph Mair wrote: we are proud to release a hardware extension for our beloved Freerunner: a navigation board! Very impressive. Congratulations ! Thank you! I guess the next level would be to make a board that fits into one of the Embedded Air (tm) pockets also have some RF transceiver ;-) Well, I've got a lot of other crazy ideas to fill these pockets, I just don't have enough time to realize them all. I'll try to do a RF transceiver during this summer (it has been on my list for several month already), so expect the first prototypes for autumn. Do you have any specific requirements which I should take into account? :) Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Saturday 01 May 2010 14:56:52 omcomali@porcupinefactory.org wrote: On Sat, 1 May 2010 13:48:58 +0200 Christoph Mair m...@chonyota.net wrote: we are proud to release a hardware extension for our beloved Freerunner: a navigation board! Great work! Are you going to distribute it? If yes, what's the price of one? If no, what's the cost of the modules needed to assemble one (pardon me if this question is stupid)? The price for all parts is about 70€ without shipping costs. The PCB is 3€, in case you want to buy everything else yourself. Most parts are available from digikey. The gyroscopes can be bought from http://invensense.com or from a distributor near you. If you want a DIY-kit, I can send you everything needed to build it. Soldering experience is definitively required. The QFN chips (gyros and compass) are somewhat difficult to handle, but you can reflow-solder them in a pizza oven. I could assemble one for you, but this solution does not scale. It took me about 5 hours to finish the first one, and an additional hour to find and remove all the short circuits. :P If there is enough interest I'll try to find someone which builds and sells ready made modules. Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Am 01.05.2010 um 17:30 schrieb Christoph Mair: On Saturday 01 May 2010 14:56:52 omcomali@porcupinefactory.org wrote: On Sat, 1 May 2010 13:48:58 +0200 Christoph Mair m...@chonyota.net wrote: we are proud to release a hardware extension for our beloved Freerunner: a navigation board! Great work! I agree 120%! Are you going to distribute it? If yes, what's the price of one? If no, what's the cost of the modules needed to assemble one (pardon me if this question is stupid)? The price for all parts is about 70€ without shipping costs. The PCB is 3€, in case you want to buy everything else yourself. Most parts are available from digikey. The gyroscopes can be bought from http://invensense.com or from a distributor near you. If you want a DIY-kit, I can send you everything needed to build it. Soldering experience is definitively required. The QFN chips (gyros and compass) are somewhat difficult to handle, but you can reflow- solder them in a pizza oven. I could assemble one for you, but this solution does not scale. It took me about 5 hours to finish the first one, and an additional hour to find and remove all the short circuits. :P If there is enough interest I'll try to find someone which builds and sells ready made modules. If you need help with SMD work for the Freerunner, we can offer our experience for doing the buzz, bass, 1024 reworks. And, we can add your design to our shop so that you don't have to handle all the individual requests. Please contact me by private mail, Nikolaus Golden Delicious Computers GmbHCo. KG Buchenstr. 3 D-82041 Oberhaching +49-89-54290367 http://www.handheld-linux.com AG München, HRA 89571 VAT DE253626266 Komplementär: Golden Delicious Computers Verwaltungs GmbH Oberhaching, AG München, HRB 16602 Geschäftsführer: Dr. Nikolaus Schaller Digital Tools for Independent People ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Congrats! Will I get a fully assembled one for free if I promise to implement FSO DBus APIs? :) Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Christoph Mair wrote: Well, I've got a lot of other crazy ideas to fill these pockets, I just don't have enough time to realize them all. Wow, I would have never imagined that anyone else could experience this problem, too ;-) Do you have any specific requirements which I should take into account? :) Hmm, how about must not interfere with GPS operation ? ;-) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freeware != free software??? Re: Navigation
a) the group free software is nothing but a combination of an adjective and a substantive, the adjective qualifying the substantive That might be the case, but in the context of distributing a piece of software in the context of GNU/Linux, free software refers to the FSF's notion. Any other use is a misuse, Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
freeware != free software??? Re: Navigation
I think you're now confusing free software with freeware. Free software app has to be open source (but not in opposite way - freeware and open source apps not always are free software) huh? since when and who made that decision? for all i know, the line goes between open source and free. open source has not to be free and free has not to be open source. to signify what you have in mind, the term foss was coined. and just the need to add f signifies that free is not open source per se (and vice versa of course). Remember, in free software term free means freedom, not free beer (as in freeware) :P that is only _one_ meaning. as human language goes, the very same word might have a lot of meanings -- depending on context, speaker, time or place. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freeware != free software??? Re: Navigation
On Tue, 5 Jan 2010, arne anka wrote: [Sebastian Krzyszkowiak wrote:] I think you're now confusing free software with freeware. Free software app has to be open source (but not in opposite way - freeware and open source apps not always are free software) huh? since when and who made that decision? for all i know, the line goes between open source and free. open source has not to be free and free has not to be open source. to signify what you have in mind, the term foss was coined. and just the need to add f signifies that free is not open source per se (and vice versa of course). Remember, in free software term free means freedom, not free beer (as in freeware) :P that is only _one_ meaning. as human language goes, the very same word might have a lot of meanings -- depending on context, speaker, time or place. for the sake of record keeping (and because i think it's an important distinction, though i accept that others disagree): the term free software was coined in or before 1989, when the GPLv1 was published by the free software foundation [1]. it quite clearly embedded the definition of free that sebastian refers to when it said: When we speak of free software, we are referring to freedom, not price. Specifically, the General Public License is designed to make sure that you have the freedom to give away or sell copies of free software, that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. . the term free software may well have been in use before then, but it was set in stone by 1989. the term open source was coined in early 1998 [2], nearly a decade later, by a group of people who _inter alia_ objected to the ambiguous meaning of free in ordinary english. FLOSS and FOSS were terms coined later, off the back of the term open source. it's true that english is still ambiguous in its definition of free, but it's not fair to say that free software is an ambiguous term. it has been precisely defined for over 20 years, long before the term open source was coined. when sebastian speaks of free software, i think he's right to impute the FSF's definition of freedon to it. please by all means use the terms open source, FOSS, FLOSS and so on if you find they help crystallise your thinking, but arne, whilst i hugely admire your software chops and appreciate the work you've done, i think you're wrong to insist that others join you because you think free software means only free as in beer. hopefully i'm not offending anyone by jumping in with a bit of history! -- Tom Yates - http://www.teaparty.net [1] http://www.gnu.org/licenses/gpl-1.0.txt [2] http://en.wikipedia.org/wiki/Open_source : The decision by some people in the free software movement to use the label “open source” came out of a strategy session held at Palo Alto, California, in reaction to Netscape's January 1998 announcement of a source code release for Navigator.___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freeware != free software??? Re: Navigation
the term free software was coined in or before 1989, when the GPLv1 was published by the free software foundation [1]. a) the group free software is nothing but a combination of an adjective and a substantive, the adjective qualifying the substantive b) qualifying a substantive with free has been in use long before the creation of software c) free software is in no way an unique term or used uniquely by the FSF -- the sentence you are quoting very clearly proves that by saying When we speak of free software ie, the term is used in a certain sense in a certain context (the GPL) -- but there's no way, the GPL is globally applicable ot the authors are in any way authorized to rule the use of those very common and widely used words in a very common grammatical construction. to conclude the discussion: sebastian would be right _only_ if somewhere in the discussion all participants had agreed to put the software in question under the GPL or at least use the GPL's definition. i can't recall, that has ever happend -- insofar any claim to use the GPL's definition as the solely applicable one is not justified! it is understandable to think in the trems of the GPL but it is not the only way to think. thus, if any author claims his/her software to be free software, he/she is entitled to it -- only if he/she accepted the GPL's definition as the binding definition of the term, his/her software has to meet the requirements laid down in the GPL. but arne, whilst i hugely admire your software chops and appreciate the work you've done, i don't know, what exactly you are talking about, but thanks anyway :-) i think you're wrong to insist that others join you because you think free software means only free as in beer. i don't. as i hopefully made clear, i think the meaning of free (or free software) has to be defined before accusing somebody of misuse and that definition was (and is) still lacking. free might be as in beer or speech or nothing to do (and those of us coming from eg the former communist parts of europe, will remember that not only the meaning of free might differ but even the extend involved), but that is not clear beforehand and certainly not implicit, even if most of us tend to think in therms of the GPL. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freeware != free software??? Re: Navigation
On Tue, Jan 05, 2010 at 01:21:50PM +0100, arne anka wrote: the term free software was coined in or before 1989, when the GPLv1 was published by the free software foundation [1]. a) the group free software is nothing but a combination of an adjective and a substantive, the adjective qualifying the substantive b) qualifying a substantive with free has been in use long before the creation of software c) free software is in no way an unique term or used uniquely by the FSF -- the sentence you are quoting very clearly proves that by saying When we speak of free software ie, the term is used in a certain sense in a certain context (the GPL) -- but there's no way, the GPL is globally applicable ot the authors are in any way authorized to rule the use of those very common and widely used words in a very common grammatical construction. Qualifying a substantive with free is far older yes, but that is not a point, nor is a) a point. c) may be a point but they're really just bringing clearity cause the word is fuzzy. to conclude the discussion: sebastian would be right _only_ if somewhere in the discussion all participants had agreed to put the software in question under the GPL or at least use the GPL's definition. i can't recall, that has ever happend -- insofar any claim to use the GPL's definition as the solely applicable one is not justified! If one is to be used then that one should be used. Ethymologically that is right, but also the other usage of the word isn't really widely spread nor accepted by many today, it also makes no sense. it is understandable to think in the trems of the GPL but it is not the only way to think. thus, if any author claims his/her software to be free software, he/she is entitled to it -- only if he/she accepted the GPL's definition as the binding definition of the term, his/her software has to meet the requirements laid down in the GPL. GPL is not the only free license. Furthermore, if you by using the term free software to describe software that is not free but gratis, you have misused the word haven't you? but arne, whilst i hugely admire your software chops and appreciate the work you've done, i don't know, what exactly you are talking about, but thanks anyway :-) i think you're wrong to insist that others join you because you think free software means only free as in beer. i don't. as i hopefully made clear, i think the meaning of free (or free software) has to be defined before accusing somebody of misuse and that definition was (and is) still lacking. free might be as in beer or speech or nothing to do (and those of us coming from eg the former communist parts of europe, will remember that not only the meaning of free might differ but even the extend involved), but that is not clear beforehand and certainly not implicit, even if most of us tend to think in therms of the GPL. Yes free may be interpreted as free of duties (which i belive is what you meant with nothing to do) however interpreteing it as free of charge is still not a very good thing cause it breaks the definition of free. Because free is such a fuzzy word, mainly due to misusage of the word one can use the words libre or gratis to distinguish them. Open source is however not the same as FLOSS or Free/Libre Software. The Open Source Movement have instead choosen to abandom the ethical principle of freedom and only promote the use of Open Source software that might not be libre (free as in freedom), which is not the same idea as the Free Software movement has. For the Free Software movement the idea of Free/Libre Software is that it should be free as in freedom. Not just open for anyone to examine as is the case with Open Source. And mainly because there is such a large movement of Free Software (free as in freedom) and the usage of free while in the discussion of software the usage of the word free in regards to software is in any case but the term Freeware analogous with libre software. And you know what? Free as used in free of charge often can be intepreted as you are free to do whatever you want to do with it, not only that it is gratis. If i have a free soda pop for you, then you can use it for whatever, even give it away to someone else.. for if i attached criterias for why it is gratis then would it still be free? Please clean up your own language usage to avoid things like this, it is tedious to have to be carefull about the word free is applied only because people do not consider their own language usage or the consistancy in their language. /end of arrogant rant about language usage. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freeware != free software??? Re: Navigation
/end of arrogant rant about language usage. this is getting too long for me :) just download the relevant packages which this thread started about and read license in there, it might help your understanding :)) cheers Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freeware != free software??? Re: Navigation
2010/1/5 Viktor Lindberg l...@leth.yi.org: The Open Source Movement have instead choosen to abandom the ethical principle of freedom and only promote the use of Open Source software that might not be libre (free as in freedom), which is not the same idea as the Free Software movement has. [...] Not just open for anyone to examine as is the case with Open Source. FWIW, that is not my understanding. I believe that the practical requirements of Open Source and Free Software are mostly identical. The difference is one of philosophical emphasis: the Open Source movement chooses to emphasize practical and tangible benefits from using and working on their projects, whereas the Free Software movement emphasizes freedom, even if it means working in the short term with an inferior product. I hope that's useful to someone (and correct!) ... Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freeware != free software??? Re: Navigation
Since this is a mailinglist about openmoko's «free»runner, I think it's normal to assume everyone on this mailinglist understands the idea behind the free philosophy. On Tue, 2010-01-05 at 16:09 +0100, Viktor Lindberg wrote: On Tue, Jan 05, 2010 at 01:21:50PM +0100, arne anka wrote: the term free software was coined in or before 1989, when the GPLv1 was published by the free software foundation [1]. a) the group free software is nothing but a combination of an adjective and a substantive, the adjective qualifying the substantive b) qualifying a substantive with free has been in use long before the creation of software c) free software is in no way an unique term or used uniquely by the FSF -- the sentence you are quoting very clearly proves that by saying When we speak of free software ie, the term is used in a certain sense in a certain context (the GPL) -- but there's no way, the GPL is globally applicable ot the authors are in any way authorized to rule the use of those very common and widely used words in a very common grammatical construction. Qualifying a substantive with free is far older yes, but that is not a point, nor is a) a point. c) may be a point but they're really just bringing clearity cause the word is fuzzy. to conclude the discussion: sebastian would be right _only_ if somewhere in the discussion all participants had agreed to put the software in question under the GPL or at least use the GPL's definition. i can't recall, that has ever happend -- insofar any claim to use the GPL's definition as the solely applicable one is not justified! If one is to be used then that one should be used. Ethymologically that is right, but also the other usage of the word isn't really widely spread nor accepted by many today, it also makes no sense. it is understandable to think in the trems of the GPL but it is not the only way to think. thus, if any author claims his/her software to be free software, he/she is entitled to it -- only if he/she accepted the GPL's definition as the binding definition of the term, his/her software has to meet the requirements laid down in the GPL. GPL is not the only free license. Furthermore, if you by using the term free software to describe software that is not free but gratis, you have misused the word haven't you? but arne, whilst i hugely admire your software chops and appreciate the work you've done, i don't know, what exactly you are talking about, but thanks anyway :-) i think you're wrong to insist that others join you because you think free software means only free as in beer. i don't. as i hopefully made clear, i think the meaning of free (or free software) has to be defined before accusing somebody of misuse and that definition was (and is) still lacking. free might be as in beer or speech or nothing to do (and those of us coming from eg the former communist parts of europe, will remember that not only the meaning of free might differ but even the extend involved), but that is not clear beforehand and certainly not implicit, even if most of us tend to think in therms of the GPL. Yes free may be interpreted as free of duties (which i belive is what you meant with nothing to do) however interpreteing it as free of charge is still not a very good thing cause it breaks the definition of free. Because free is such a fuzzy word, mainly due to misusage of the word one can use the words libre or gratis to distinguish them. Open source is however not the same as FLOSS or Free/Libre Software. The Open Source Movement have instead choosen to abandom the ethical principle of freedom and only promote the use of Open Source software that might not be libre (free as in freedom), which is not the same idea as the Free Software movement has. For the Free Software movement the idea of Free/Libre Software is that it should be free as in freedom. Not just open for anyone to examine as is the case with Open Source. And mainly because there is such a large movement of Free Software (free as in freedom) and the usage of free while in the discussion of software the usage of the word free in regards to software is in any case but the term Freeware analogous with libre software. And you know what? Free as used in free of charge often can be intepreted as you are free to do whatever you want to do with it, not only that it is gratis. If i have a free soda pop for you, then you can use it for whatever, even give it away to someone else.. for if i attached criterias for why it is gratis then would it still be free? Please clean up your own language usage to avoid things like this, it is tedious to have to be carefull about the word free is applied only because people do not consider their own language usage or the consistancy in their language. /end of arrogant rant about language
Re: freeware != free software??? Re: Navigation
On Tue, Jan 05, 2010 at 03:39:42PM +, Neil Jerram wrote: 2010/1/5 Viktor Lindberg l...@leth.yi.org: The Open Source Movement have instead choosen to abandom the ethical principle of freedom and only promote the use of Open Source software that might not be libre (free as in freedom), which is not the same idea as the Free Software movement has. [...] Not just open for anyone to examine as is the case with Open Source. FWIW, that is not my understanding. I believe that the practical requirements of Open Source and Free Software are mostly identical. The difference is one of philosophical emphasis: the Open Source movement chooses to emphasize practical and tangible benefits from using and working on their projects, whereas the Free Software movement emphasizes freedom, even if it means working in the short term with an inferior product. I don't wish to be rude but you're not actually contradicting anything i'm saying afaict thought you are putting the words diffrently to emphasis that Open Source would have a better technical solution, i'm not sure that is the case, it might be true to some extent yes. But when you have virtues and value ethics highly you might have to avoid certain methods which you consider evil to some extent. And frankly to use any GNU/Linux distribution as an example, Free Software is not that technically inferior. In fact most GNU/Linux systems are have a much higher rate of free software as part of the system then non free open source software. There are even distributions that have strict policies agains including non free software that works perfectly well with perhaps the small exceptions of some few hardware drivers, in this case you can just avoid buying hardware from vendors who completle ignores the call for free software. Not to forget OpenBSD which is 100% Free Software and is renown for being a really good technical solution. Yes it is true that the Open Source movement likes to focus on the technical advantages of Open Source Software, but it's not true to say that good technical solution is ignored by the Free Software movement. However the big diffrence lies as you said in the philosophical part, that ethical apsects of software freedom, thus somtimes the Free Software movement is sometimes happy with a suboptimal solution for the sake of moral issues. (in my case i consider linux a subotpimal technical solution, but it allows for me to run a fully free OS) I hope that's useful to someone (and correct!) ... 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: freeware != free software??? Re: Navigation
2010/1/5 Viktor Lindberg l...@leth.yi.org: I don't wish to be rude but you're not actually contradicting anything i'm saying afaict Actually I think I am a bit. You said Not just open for anyone to examine as is the case with Open Source, which sounds to me like you are saying that people cannot modify or redistribute Open Source code. But in fact they can, according to every OSI-approved license that I've heard of. thought you are putting the words diffrently to emphasis that Open Source would have a better technical solution, i'm not sure that is the case, it might be true to some extent yes. It sounds like you think that I'm supporting the Open Source point of view. I'm not; I was just trying to describe the philosophical difference as clearly as possible. As it happens, I strongly prefer the Free Software point of view - and I completely agree with what you write next: But when you have virtues and value ethics highly you might have to avoid certain methods which you consider evil to some extent. And frankly to use any GNU/Linux distribution as an example, Free Software is not that technically inferior. [...] Yes it is true that the Open Source movement likes to focus on the technical advantages of Open Source Software, but it's not true to say that good technical solution is ignored by the Free Software movement. Well I certainly hope not, given that I've been working (on and off) on a FSF project for more than 10 years now... :-) Best wishes, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navigation
c'mon, you know he meant well I can only applaud new pieces of software for our freerunners, so keep up the good work I personally think it's entirely up to you to release or not release the source files (afterall, you could also make a programme people have to pay for) but it might be interesting for both you and the community; maybe someone has a good idea or a suggestion to make? maybe someone will propose a patch? anyway, it's still up to you (imho) just have fun! On Sun, Jan 3, 2010 at 10:47 PM, Mike Crash m...@mikecrash.com wrote: This means that it is preview and not releasable yet. I know what it free software - but it is up to author, when he makes releases. And if he makes it at all. This is only to know, that it is not sleeping. So please don't be fidgety - I have spent on this 7 months, every day 2-3 hours, many times to late night (to 2 am) and I can thank god I have so lovely family to allow that. This is true for other my projects too. Why don't I buy navigation for 200 bucks instead of spending my rare time that would cost by the way my employer thousands? With no donations and no gratitude. Anyway, I should slow down... Neil Jerram wrote: 2010/1/3 Mike Crash m...@mikecrash.com: Happy new year everyone! If you want to look at progress, here is first version of MC Navi: http://www.mikecrash.com/index.php?name=Newsfile=articleid=116 This is nice news, but what is it with the sorry, no source code yet thing? Mike, I don't actually mean to complain at you in particular. It seems to me that a lot of people write something like that, especially with their early releases. I just don't understand why, and I'm afraid that your post has pushed me over the edge into saying something about it. Do people not know what Free Software means? (Plus it's not hard to find a way of hosting source code...) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/Navigation-tp4141297p4247408.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: Navigation
hi,
If you want to look at progress, here is first version of MC Navi:
http://www.mikecrash.com/index.php?name=Newsfile=articleid=116
Currently not for usage, only as preview for Debian users.
downloaded the packages on my laptop:
van...@vanek:/tmp$ ./osm2mcmap
bash: ./osm2mcmap: cannot execute binary file
van...@vanek:/tmp$ strace ./osm2mcmap
execve(./osm2mcmap, [./osm2mcmap], [/* 38 vars */]) = -1 ENOEXEC
(Exec format error) dup(2) = 3
fcntl64(3, F_GETFL) = 0x8002 (flags
O_RDWR|O_LARGEFILE) fstat64(3, {st_mode=S_IFCHR|0620,
st_rdev=makedev(136, 3), ...}) = 0 mmap2(NULL, 4096,
PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb803e000
_llseek(3, 0, 0xbfb4d7d0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, strace: exec: Exec format error\n, 32strace: exec: Exec
format error ) = 32 close(3)= 0
munmap(0xb803e000, 4096)= 0
exit_group(1) = ?
i get the same with the mcnavi
i get mcnavi trying to run on latest shr-u, but as i cannot convert
the map, i get:
# ./mcnavi
Cannot open map
sources would help to get the converter running...
cheers
Petr
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Navigation
2010/1/4 Yorick Moko yorickm...@gmail.com: c'mon, you know he meant well Yes indeed. I apologize for raising this issue on Mike's thread; I should have started a new thread and so not have singled out Mike in particular. Best wishes, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navigation
On Mon, Jan 4, 2010 at 9:43 PM, Neil Jerram neiljer...@googlemail.comwrote: 2010/1/4 Yorick Moko yorickm...@gmail.com: c'mon, you know he meant well Yes indeed. I apologize for raising this issue on Mike's thread; I should have started a new thread and so not have singled out Mike in particular. Best wishes, Neil just my 2c: maybe you confuse free software with open source software and viceversa... Mike releases his software as free software now... maybe late as an open source one. But that's not the topic. Keep on going guys! d ___ 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: Navigation
On 1/4/10, Davide Scaini dsca...@gmail.com wrote: On Mon, Jan 4, 2010 at 9:43 PM, Neil Jerram neiljer...@googlemail.comwrote: 2010/1/4 Yorick Moko yorickm...@gmail.com: c'mon, you know he meant well Yes indeed. I apologize for raising this issue on Mike's thread; I should have started a new thread and so not have singled out Mike in particular. Best wishes, Neil just my 2c: maybe you confuse free software with open source software and viceversa... Mike releases his software as free software now... maybe late as an open source one. But that's not the topic. Keep on going guys! d ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I think you're now confusing free software with freeware. Free software app has to be open source (but not in opposite way - freeware and open source apps not always are free software) What he did is freeware. Open source could be when I'd be able to look at source, and free software would be when I'd be able to do with that source what I want. Remember, in free software term free means freedom, not free beer (as in freeware) :P -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navigation
Happy new year everyone! If you want to look at progress, here is first version of MC Navi: http://www.mikecrash.com/index.php?name=Newsfile=articleid=116 Currently not for usage, only as preview for Debian users. Mike Crash wrote: Hello everyone, I only want to inform you, that I am working on new navigation for the Freerunner, current name is MC Navi, but may change. Screenshots here: http://www.mikecrash.com/index.php?name=Newsfile=articleid=115 -- View this message in context: http://n2.nabble.com/Navigation-tp4141297p4246609.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: Navigation
On Sun, Jan 3, 2010 at 6:40 PM, Mike Crash m...@mikecrash.com wrote: Happy new year everyone! If you want to look at progress, here is first version of MC Navi: http://www.mikecrash.com/index.php?name=Newsfile=articleid=116 Currently not for usage, only as preview for Debian users. Mike Crash wrote: Hello everyone, I only want to inform you, that I am working on new navigation for the Freerunner, current name is MC Navi, but may change. Screenshots here: http://www.mikecrash.com/index.php?name=Newsfile=articleid=115 -- View this message in context: http://n2.nabble.com/Navigation-tp4141297p4246609.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 don't stop it now ;-) great to have choice... is it faster than navit (even if buggy but just to know)? d ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navigation
2010/1/3 Mike Crash m...@mikecrash.com: Happy new year everyone! If you want to look at progress, here is first version of MC Navi: http://www.mikecrash.com/index.php?name=Newsfile=articleid=116 This is nice news, but what is it with the sorry, no source code yet thing? Mike, I don't actually mean to complain at you in particular. It seems to me that a lot of people write something like that, especially with their early releases. I just don't understand why, and I'm afraid that your post has pushed me over the edge into saying something about it. Do people not know what Free Software means? (Plus it's not hard to find a way of hosting source code...) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navigation
This means that it is preview and not releasable yet. I know what it free software - but it is up to author, when he makes releases. And if he makes it at all. This is only to know, that it is not sleeping. So please don't be fidgety - I have spent on this 7 months, every day 2-3 hours, many times to late night (to 2 am) and I can thank god I have so lovely family to allow that. This is true for other my projects too. Why don't I buy navigation for 200 bucks instead of spending my rare time that would cost by the way my employer thousands? With no donations and no gratitude. Anyway, I should slow down... Neil Jerram wrote: 2010/1/3 Mike Crash m...@mikecrash.com: Happy new year everyone! If you want to look at progress, here is first version of MC Navi: http://www.mikecrash.com/index.php?name=Newsfile=articleid=116 This is nice news, but what is it with the sorry, no source code yet thing? Mike, I don't actually mean to complain at you in particular. It seems to me that a lot of people write something like that, especially with their early releases. I just don't understand why, and I'm afraid that your post has pushed me over the edge into saying something about it. Do people not know what Free Software means? (Plus it's not hard to find a way of hosting source code...) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/Navigation-tp4141297p4247408.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: Navigation
2010/1/3 Mike Crash m...@mikecrash.com: This means that it is preview and not releasable yet. This makes no sense. How can the binary be releasable, but the source code not? I know what it free software - but it is up to author, when he makes releases. And if he makes it at all. I agree that it is completely your choice when, whether and what to release. But you should not claim that your project is free software if you do not release the source code. To be fair, I don't know if you _have_ ever claimed that your project is free software. I basically just assume that everyone on this list is intending to follow the conventions of free software - perhaps that's a bad assumption on my part. This is only to know, that it is not sleeping. That is appreciated, thanks! So please don't be fidgety - I have spent on this 7 months, every day 2-3 hours, many times to late night (to 2 am) and I can thank god I have so lovely family to allow that. This is true for other my projects too. Why don't I buy navigation for 200 bucks instead of spending my rare time that would cost by the way my employer thousands? Understood; I think we all know these feelings... Personally I'm afraid I can no longer manage to work at that kind of intensity, but I fondly remember the days when I could and did. And, I really believe that releasing the source code could help you and your project! With no donations and no gratitude. Those are bad reasons for working on free software, of course, but I would guess that you didn't really mean them...? Anyway, I should slow down... Not because of my comment, I hope! Best wishes, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] NeronGPS no worky (was Re: [QtMoko] GPS navigation apps for QtMoko)
Hi, FYI, I tested it on the original QtExtended 4.4.3 from Nokia, then on QtMoko v14, QtMoko v15 and the recent QtMoko v16. I had no issues with these platforms. Rgds, Thierry - Mail Original - De: Brolin Empey bro...@brolin.be À: List for Openmoko community discussion community@lists.openmoko.org Envoyé: Dimanche 20 Décembre 2009 00h31:30 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: [QtMoko] NeronGPS no worky (was Re: [QtMoko] GPS navigation apps for QtMoko) 2009/12/16 Tony McKeehan mck...@rpi.edu Yeah, NeronGPS is in the QtMoko feeds and all you need to install it is a recent version of QtMoko and an internet connection. Is QtMoko v14 sufficiently recent? It's native to the Qt framework that QtMoko uses and doesn't need an X server. It has a slightly different interface from Navit and tango, but it's pretty easy to get used to. It also does not even run on my FreeRunner: every time I try running it from the QtEI Applications list, I get a dialog saying: Application terminated NeronGPS was terminated due to application error. Any ideas? ___ 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
[QtMoko] NeronGPS no worky (was Re: [QtMoko] GPS navigation apps for QtMoko)
2009/12/16 Tony McKeehan mck...@rpi.edu Yeah, NeronGPS is in the QtMoko feeds and all you need to install it is a recent version of QtMoko and an internet connection. Is QtMoko v14 sufficiently recent? It's native to the Qt framework that QtMoko uses and doesn't need an X server. It has a slightly different interface from Navit and tango, but it's pretty easy to get used to. It also does not even run on my FreeRunner: every time I try running it from the QtEI Applications list, I get a dialog saying: *Application terminated* *NeronGPS* was terminated due to application error. Any ideas? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] GPS navigation apps for QtMoko
Could it be it's not in de debian repository's? Tony McKeehan wrote: Yeah, NeronGPS is in the QtMoko feeds and all you need to install it is a recent version of QtMoko and an internet connection. It's native to the Qt framework that QtMoko uses and doesn't need an X server. It has a slightly different interface from Navit and tango, but it's pretty easy to get used to. -Tonym Brolin Empey wrote: Hello list, Are there any GPS navigation apps for QtMoko, i.e., any usable without an X server? I cannot use QX because every time I try, I end up having to remove the battery from my FreeRunner because my FreeRunner locks up and is unusable. I wanted to use Navit, but it requires a working X server. Alternately, is there any way to get a working (non-QX) X server on QtMoko, or use QtMoko with an X server (maybe on plain Debian)? Months ago, I asked for recommendations of MicroSDHC cards to buy to install plain Debian on. I still have not even found a place to buy any of the recommended cards because I have not made doing so a sufficiently high priority for it to ever be done. My parents gave me a Garmin nûvi GPS navigator (I do not remember which model, but I can find out if you want) as an early Christmas gift, so I at least have a working GPS navigation solution, but it would be better if I could use my FreeRunner as a GPS navigator. I never use cell phones while driving because doing so is a recipe for disaster for me: I always pull over and stop before using a cell phone. I am mentioning this because I wonder if it simplifies finding a GPS navigation app because I do not use cell phones while driving, so I do not have to answer nor make calls while the GPS navigation app is running. I still need to log missed calls and receive SMS messages, though. I also do not want messages about missed calls or received SMS messages blocking my view of the GPS navigation app on the screen while I am driving because I may not even be able to safely pull over to use my FreeRunner. I am using QtMoko v14, but will see if v15 looks like it is worth upgrading to. Thanks, Brolin -- Sometimes I forget how to do small talk: http://xkcd.com/222/ “If you have to ask why, you’re not a member of the intended audience.” — Bob Zimbinski, http://webpages.mr.net/bobz/ttyquake/ ___ 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: [QtMoko] GPS navigation apps for QtMoko
On Thursday 17 of December 2009 18:43:02 Hans Zimmerman wrote: Could it be it's not in de debian repository's? If i know right then yes. The project was announced just a few months ago. Building Debian package will probably not take too much effort except that the Qtopia GPS API would have to be handled somehow. Sources can be found here [1]. The problem with QtMoko and Debian packages is that most of Debian packages are built for Qt/X11 while we use Qt/framebuffer and that means different set of dependecies and probably also different binaries. That's why we have our package feed which has also the advantage that it works on QtMoko distros based on open embedded/arch rootfs. Regards Radek [1] http://github.com/tvuillaume/NeronGPS/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QtMoko] GPS navigation apps for QtMoko
Hello list, Are there any GPS navigation apps for QtMoko, i.e., any usable without an X server? I cannot use QX because every time I try, I end up having to remove the battery from my FreeRunner because my FreeRunner locks up and is unusable. I wanted to use Navit, but it requires a working X server. Alternately, is there any way to get a working (non-QX) X server on QtMoko, or use QtMoko with an X server (maybe on plain Debian)? Months ago, I asked for recommendations of MicroSDHC cards to buy to install plain Debian on. I still have not even found a place to buy any of the recommended cards because I have not made doing so a sufficiently high priority for it to ever be done. My parents gave me a Garmin nûvi GPS navigator (I do not remember which model, but I can find out if you want) as an early Christmas gift, so I at least have a working GPS navigation solution, but it would be better if I could use my FreeRunner as a GPS navigator. I never use cell phones while driving because doing so is a recipe for disaster for me: I always pull over and stop before using a cell phone. I am mentioning this because I wonder if it simplifies finding a GPS navigation app because I do not use cell phones while driving, so I do not have to answer nor make calls while the GPS navigation app is running. I still need to log missed calls and receive SMS messages, though. I also do not want messages about missed calls or received SMS messages blocking my view of the GPS navigation app on the screen while I am driving because I may not even be able to safely pull over to use my FreeRunner. I am using QtMoko v14, but will see if v15 looks like it is worth upgrading to. Thanks, Brolin -- Sometimes I forget how to do small talk: http://xkcd.com/222/ “If you have to ask why, you’re not a member of the intended audience.” — Bob Zimbinski, http://webpages.mr.net/bobz/ttyquake/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] GPS navigation apps for QtMoko
Yeah, NeronGPS is in the QtMoko feeds and all you need to install it is a recent version of QtMoko and an internet connection. It's native to the Qt framework that QtMoko uses and doesn't need an X server. It has a slightly different interface from Navit and tango, but it's pretty easy to get used to. -Tonym Brolin Empey wrote: Hello list, Are there any GPS navigation apps for QtMoko, i.e., any usable without an X server? I cannot use QX because every time I try, I end up having to remove the battery from my FreeRunner because my FreeRunner locks up and is unusable. I wanted to use Navit, but it requires a working X server. Alternately, is there any way to get a working (non-QX) X server on QtMoko, or use QtMoko with an X server (maybe on plain Debian)? Months ago, I asked for recommendations of MicroSDHC cards to buy to install plain Debian on. I still have not even found a place to buy any of the recommended cards because I have not made doing so a sufficiently high priority for it to ever be done. My parents gave me a Garmin nûvi GPS navigator (I do not remember which model, but I can find out if you want) as an early Christmas gift, so I at least have a working GPS navigation solution, but it would be better if I could use my FreeRunner as a GPS navigator. I never use cell phones while driving because doing so is a recipe for disaster for me: I always pull over and stop before using a cell phone. I am mentioning this because I wonder if it simplifies finding a GPS navigation app because I do not use cell phones while driving, so I do not have to answer nor make calls while the GPS navigation app is running. I still need to log missed calls and receive SMS messages, though. I also do not want messages about missed calls or received SMS messages blocking my view of the GPS navigation app on the screen while I am driving because I may not even be able to safely pull over to use my FreeRunner. I am using QtMoko v14, but will see if v15 looks like it is worth upgrading to. Thanks, Brolin -- Sometimes I forget how to do small talk: http://xkcd.com/222/ “If you have to ask why, you’re not a member of the intended audience.” — Bob Zimbinski, http://webpages.mr.net/bobz/ttyquake/ ___ 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: Navigation
This is not a good idea. Rendering such amount of data will take a (long) while, also there si problem where to save it (little memory and slow card), also you need any map angle at any time. And rendering speed is not a big problem, it seems to work fine (or at least satisfactorily). Yorick Moko wrote: might be an idea worth considering: have the possibility to calculate a route, and pre-render the bitmaps of your route (at a few zoom-levels) This way it doesn't have to be done on the fly when you know for example where you are going to travel to when you don't follow the planned route it will of course render new files when nescessary you should also have the option to delete them afterwards of course or maybe a setting two way trip; this setting wil save all the rendered files on your way to your destination, use the pre-rendered images on your way back, and ask you if you want to delete them when you return home just an idea On Mon, Dec 14, 2009 at 10:32 AM, Mike Crash m...@mikecrash.com wrote: Sure I'm using speed data from OSM and if not available, set it based on way type and common speeds. I can find shortest and fastest path. No detection if road is in the city yet. I made some progress in last days and I'm going to use it for the first time to drive home today :) Bastian Muck wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Crash schrieb: I use A* for routing, it is usable, but still not what I expect. But I have some improvements in my mind :) I need to create rerouting now and to test it in real life I don't have any idea, how the code looks like, but I guess, that you use gps-positions as heuristic and distances as edge-weights. That means that you always get the shortest path. If you want to get the fastes path, then you have to use timevalues calculated by possible speed and edge-length. With openstreetmaps that can be difficult, because many roads don't have any speedsproperties. You often only can use the roadtype depending on country to guess the speed. Maybe you used this, but in a first shit, I guess that you don't. I hope these ideas can help you improving your tool. Greetings Bastian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLI6B6lYiDScJJ+7QRAugfAKD4cLPiucAwIP2eXajmSlMdRSyKxQCg3q6D bChe84DmVlpTa9dx4dBzE2o= =II9r -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/Navigation-tp4141297p4163143.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 -- View this message in context: http://n2.nabble.com/Navigation-tp4141297p4170094.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
