[omgps] collect feature requests

[mqy]

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
>>> community at lists.openmoko.org
>>> http://lists.openmoko.org/mailman/listinfo/community
>>>
>>>
>> 
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> 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.