Common API's (was: forked projects)

Krzysztof, you're exactly right. I think we do need some kind of common API 
that tries to abstract away the astounding diversity of hardware that we 
have. For example, Tak and I are working on a porting OSGPS to an integer 
math only ARM7TDMI (the GP4020), and Matt is working on a software only 
receiver. It would be great to re-use as much code as we can.

I think breaking it up into the different task levels is a good idea... we 
have the correlator level, the pseudorange level, the navigation level. But 
don't forget there has to be API's for down the chain too; external data 
may be needed from upper levels to be sent back down to aid correlators, 
for example.

Not to get too abstract, but: it would also be nice to be able to easily 
put these interfaces over a network; e.g., we have an FPGA correlator over 
USB to a PC, or a small GPS receiver sending pseudoranges to a flight 
computer over CAN. Maybe some kind of common packet format could handle 
these cases?

Although IANACS (I Am Not A Computer Scientist), some of my best friends 
are CS people ;) so I'll get together with them in the next few weeks and 
try and come up with some pointers about doing this.

But in the mean time, does anyone want to take a first try at this? I think 
it's going to need lots of revisions, since there are so many different 
users of OSGPS, so don't worry about getting it right on the first try.

Andrew

At 10:47 PM 3/31/2005 -0500, Krzysztof Kamieniecki wrote:

>I think a common interface between tracking and position fixing may be 
>needed. There are several groups of people that are interested in 
>different layers of GPS receivers with different sets of hardware. (pure 
>SW, correlator chipsets, FPGAs / ASICs)
>
>
>Here is what I have been pondering, as a minimal API.
>
>Each correlator/tracker  sends an asynchronous symbol up the chain at 
>about (1kS/s)
>
>All of the correlator/tracker PLL and DLL phases and cycle counts have to 
>be sampled at the same time and sent up the chain. This would also have to 
>include an internal clock value and/or sample count.
>
>The position fixing level would need to allocate and setup correlators 
>based on which SVs are in view.
>
>
>Good, Bad, Stupid?
>
>Matt Ettus wrote:
>
>>I am embarking on a project to build a GPS receiver in software around my
>>hardware, the Universal Software Radio Peripheral (USRP, see
>>http://www.ettus.com for more info).  I wanted to use OpenSourceGPS to do the
>>position fixes, but I'll have to do my own tracking, etc.
>>My question is this -- it seems that there are several disparate efforts 
>>around
>>the same code base.  There's a PCI one, RTAI linux-based one, and a 
>>couple for
>>some different hardware.  Is there a common code repository for 
>>these?  Or have
>>they forked?  It would be nice to adapt the main code base so that different
>>hardware and operating systems could be used without duplicating effort 
>>on the
>>common parts.
>>Thanks,
>>Matt Ettus
>>Ettus Research LLC
>>
>>_______________________________________________
>>opensource_gps mailing list
>>[email protected]
>>http://lists.psas.pdx.edu/cgi-bin/mailman/listinfo/opensource_gps
>
>--
>Krzysztof Kamieniecki
>callsign:KB1KLB
>mailto:[email protected]
>
>_______________________________________________
>opensource_gps mailing list
>[email protected]
>http://lists.psas.pdx.edu/cgi-bin/mailman/listinfo/opensource_gps
>


------------------------------------------------------
    Andrew Greenberg - [email protected] - 503.788.1343
------------------------------------------------------