Nice.<br><br>Regards<br>Sriranjan<br><br><div class="gmail_quote">On Wed, Jul 21, 2010 at 10:23 PM, Christoph Mair <span dir="ltr"><<a href="mailto:ml@chonyota.net">ml@chonyota.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Am Mittwoch 21 Juli 2010, 11:22:20 schrieb Dr. H. Nikolaus Schaller:<br>
<div class="im">> Am 21.07.2010 um 10:55 schrieb Helge Hafting:<br>
> > On 03. mai 2010 11:10, Jeffrey Ratcliffe wrote:<br>
> >> On 3 May 2010 11:04, Dr. H. Nikolaus Schaller<<a href="mailto:hns@goldelico.com">hns@goldelico.com</a>> wrote:<br>
> >>>> Having navigation work inside tunnels<br>
> >>>> would allow mapping them accurately for openstreetmap. And also have<br>
> >>>> underground navigation - some tunnels have got<br>
> >>>> intersections/roundabouts inside, with several possible exits.<br>
> >><br>
> >> Would navit, tangogps, etc. need a new interface to access the<br>
> >> sensors, or could the existing libraries be adapted to "correct" the<br>
> >> GPS data with additional information from the extra sensors before<br>
> >> handing it on to the GUI?<br>
> ><br>
> > The natural place for such software seems to be in gpsd itself - it<br>
> > already supports having several gps (position) devices. (Or possibly in<br>
> > a front-end to gpsd - depends on what the gpsd developer wants.) But too<br>
> > many processes / software layers is not good - it causes delays.<br>
><br>
> Well, for 1 position per second delays it may be neglectable, but you are<br>
> right - having everything in one "middle-man" daemon (gpsd) appears to be<br>
> the best architecture for me. So it hides the complexity from the<br>
> user-applications, and should be easily expandable.<br>
><br>
> As far as I know, the kernel driver for the BMP085 barometric altimeter is<br>
> already in some upstream kernel release candidate. So altitude information<br>
> can be mixed between GPS and altimeter as well.<br>
</div>Well, not in a release candidate. The patch waits in Andrew Morton's MM tree<br>
to be sent upstream. This will probably happen after 2.6.35 has been released.<br>
In the meantime I will send patches against the SHR kernel to the shr-devel<br>
mailing list. Hopefully they will be included by default when the navigation<br>
board v2 becomes available.<br>
<br>
I started to document the features of the new board:<br>
<a href="http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2" target="_blank">http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2</a><br>
<br>
This might be the right place to collect ideas or suggestions on how to use<br>
the new possibilities.<br>
<font color="#888888"><br>
Christoph<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Openmoko community mailing list<br>
<a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a><br>
<a href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank">http://lists.openmoko.org/mailman/listinfo/community</a><br>
</div></div></blockquote></div><br>