On Wed, Dec 17, 2014 at 9:10 AM, Rudolf Streif <[email protected]> wrote: >> The beauty of gpsd is that is manages non NMEA Gps (low cost, network and >> NMEA 4 multiplexed connections). >> When it comes to test, that's really nice. >> > > Agree. Since a lot of work integrating GPS devices has already been done for > gpsd, I somewhat surprised that AMB > started from scratch. >
It's not exactly true that we started from scratch. Initially we had a gpsd plugin that used libgps to communicate with the gpsd daemon. I sent out a message to the mailing list if anyone was using the gpsd plugin[1]. I didn't get any responses so the plugin was removed. The reason why the gpsnmea plugin was created was just for architectural simplicity. gpsd is a multiplexing daemon, and so is ambd. So having two multiplexers for the same thing (a GPS fix) didn't seem like an optimal solution. Also the cost of maintaining the gpsd plugin if no one was using it is also a factor. That said, there may be additional cost associated with just having the gpsnmea plugin -gpsd has a lot of support for exotic gps devices including some proprietary protocols (Garmin comes to mind). However, most modern GPS devices, as least as far as I have observed support the NMEA protocol. I have a garmin device that supports both the proprietary garmin binary protocol (one that I couldn't get working with gpsd at the time) and NMEA. If the AMB gpsd plugin would be useful, I can certainly resurrect it. But I think I'm much more interested in improving the tools and documentation in general in AMB and understanding from a non-maintainer perspective where we are lacking. [1] - https://lists.01.org/pipermail/amb/2014-April/000005.html -Kevron > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
