Re: Common API's (was: forked projects)

Just to get things started, I'll fill in details if anyone is interested

up packets:
  symbol_found
    ??? timestamp
    int correlator
    int prn
    float i
    float q

  tracking_state
    ??? timestamp
    int correlator[]
    int prn[]
    //these may be implementation dependent
    ??? state[]   
    ??? doppler_freq[]
    ??? doppler_phase[]
    ??? doppler_cycle_count[]
    ??? delay_freq[]
    ??? delay_phase[]
    ??? delay_cycle_count[] //AKA symbol count

down packets: could have some sort of response
  correlator_request:
    ??? do_at_time
    int correlator
    int prn
    //these may be implementation dependent
    ??? state
    ??? doppler_freq
    ??? doppler_phase
    ??? doppler_cycle_count
    ??? delay_freq
    ??? delay_phase
    ??? delay_cycle_count //AKA symbol count
 
   correlator_adjust_ {state, doppler_freq, doppler_phase, doppler_cycle_count, 
     
                       delay_freq, delay_phase, delay_cycle_count}
    ??? do_at_time
    int correlator
    int prn
    ??? value
   
  
    

Quoting Andrew Greenberg <[email protected]>:
> 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
> ------------------------------------------------------
> 
> 
> 
> _______________________________________________
> opensource_gps mailing list
> [email protected]
> http://lists.psas.pdx.edu/cgi-bin/mailman/listinfo/opensource_gps
>