Hehe, I just googled "ciao", Ciao bella:) First of all I have to say that fso-framework is excellent, because we do need a top level abstraction and manger to control access to system resources (especially the hardwares). As of GPS related APIs in ogpsd, UBX binary protocol is used to issue control commands (such as initialize GPS receiver, upload/download AID messages), and NMEA protocol is used to accept messages passively.
NMEA is good, because it is standard and easy to understand, easy to implement parser. but standard also means less flexibility comparing to UBX binary protocol which provides richer data and more controls. I've implemented three parsers (UBX binary, UBX NEMA, standard NEMA) and can switch on the fly. Finally I realized that it is unacceptable without supporting fso. I can choose use gpsd (or fso-gpsd) + ogpsd as data provider, but i's not battery-friendly -- fso-gpsd accepts data from ogpsd, converts them to NMEA messages, fso-gpsd users get data from it through sockets. To use ogpsd, it is obvious that omgps talks directly with ogpsd. I want better performance and free controls. UBX binary is efficient enough, so it is kept as default data provider. The common communication model of UBX binary is polling: send request, read response and optional ACK. On omgps start, it checks if ogpsd has users connected to it (for example fso-gpsd). If no existing users, omgps use UBX binary as data provider, then initialize GPS receiver (enable UBX binary protocol, disable NEMA protocol)... NOTE: the three protocols can be enabled at the same time, this means /dev/ttySAC1 can output binary + text. During omgps running, each response message is validated (header + checksum + ack). If another user of GPS receiver (say ogpsd) is started, it would re-initialize GPS, which may cause omgps read timeout, get bad data. Anyway, omgps can detect conflict and during that period other GPS receiver users may lose some data which are consumed by omgps. Upon conflict, omgps checks existing GPS receiver users via ogpsd dbus API, if the count > 0, omgps has to switch data provider to ogpsd. To get data from ogpsd you have to register signals (aysnc mode, ogpsd sends data per second) or poll in synchronous mode. So the finnaly conclusion: you can't manually switch to ogpsd. BTW, is the start time unacceptable? Ciao, mqy :) Fox Mulder wrote: > > My name is Rainer not Ciao but i forgive you. :) > > Ok so when i understand it right i can change between nativ UBX Format > and ogpsd (NMEA format?) usage. As i know ogpsd was introduced to solve > the problem of multiple programs accessing /dev/ttySAC1 and instead use > ogpsd which support multiple connections. > But what is not clear to me is how you connect to the gps with UBX > format. I thought this is only possible over /dev/ttySAC1, which would > block possible ogpsd readings, or does ogpsd support NMEA and UBX format? > So in the end i only have to switch somehow from UBX to ogpsd input in > omgps to disable the aided gps data function? > > mqy wrote: >> hi Ciao, >> >> omgps supports two data providers: (1) UBX binary and (2) fso ogpsd >> (through >> dbus). >> with #1, no way to utilize ogpsd, you know duplicate connection to >> /dev/ttySAC1 would cause unexpected result. >> >> >> Fox Mulder wrote: >>> The possibility to enable/disable aided gps start within the settings >>> would be nice since fso still does agps function by itself. So the aided >>> feed of data from omgps would do it the second time after gps start. And >>> disabling agps in omgps speeds up the start and exit time of omgps a >>> little bit. :) >>> >>> Ciao, >>> Rainer >>> >>> _______________________________________________ >>> Openmoko community mailing list >>> [email protected] >>> http://lists.openmoko.org/mailman/listinfo/community >>> >>> >> > > _______________________________________________ > Openmoko community mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3183105.html Sent from the Openmoko Community mailing list archive at Nabble.com. _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
