RE: opensource_gps Digest, Vol 11, Issue 7

"si chuanyu" <[email protected]> Fri, 28 May 2004 08:11:39 +0800
Newsgroups gmane.comp.hardware.gps.opensource
Message-ID <[email protected]>
thanks for Behzad Chenaghlou's answering.It's really helpful!
Actually I'm new to GPS, and OGS as well.So I wonder if you can give me 
some suggestions or matierals from web site which could help me better 
understanding.


>From: [email protected]
>Reply-To: [email protected]
>To: [email protected]
>Subject: opensource_gps Digest, Vol 11, Issue 7
>Date: Wed, 26 May 2004 12:00:03 -0700
>
>Send opensource_gps mailing list submissions to
>	[email protected]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://lists.psas.pdx.edu/cgi-bin/mailman/listinfo/opensource_gps
>or, via email, send a message with subject or body 'help' to
>	[email protected]
>
>You can reach the person managing the list at
>	[email protected]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of opensource_gps digest..."
>
>
>Today's Topics:
>
>    1. Re: two questions about OpenGpssim (Behzad Chenaghlou)
>    2. Re: Re: ??: code tracking (Clifford Kelley)
>    3. A question!!! (OpenSourceGPS,ogs,frame_ready) (Behzad Chenaghlou)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 26 May 2004 00:32:06 +0430
>From: "Behzad Chenaghlou" <[email protected]>
>Subject: Re: [OpenSource_GPS] two questions about OpenGpssim
>To: [email protected]
>Message-ID: <[email protected]>
>
>Hi si chuanyu
>
> > I have download the OpenGPSSim Version: 0.1.0, and compiled it using
> > visual
> > C++6.0
> >
> > I did the several steps, I mean, ogsencdec,ogsxmit and ogsrcrv. using
> > nav-01-template-01-06.txt as input file.But after I changed the output
> > of
> > ogsrcrv into ASCII(using ogsencdec), the output nav-out-01.txt has some
> > mismatch with the input file nav-01-template-01-06.txt .most of the
> > mismatching occurs at the subframe 5 and 4.
> > why this occur? or is it reasonable that there's some mismatch?
> >
>as much as I know it is because of two reasons
>1. ogsxmit adds some noise to output which you can set the amount.
>2. ogsrcvr (or better to say navigation message decoder function) is not
>able to handle subframes 4,5 yet!
>
>
>
> > I also used the 393540x36.g12 to extract the navigation data. for every
> > PRN, there are many output file with different pageno of subframe 4 and
> > subframe 5. in order to simulate GPS signal, which should be used as
> > the
> > input file of ogsencdec and ogsxmit to generate the signal?
> >
>
>If you mention to the input file format of ogsxmit you will find out that 
you
>can just have different PRN's and all the other fields of the file names 
should
>be the same (week number,time of week,page number , ...).
>so you can choose one of the files and change the prn field to PRN and
>ogsxmit will check all the prn's with same time , page no , ...
>
>
> > thanks!
> >
>
>  I hope it helps
>regards
>
>/*
>Behzad Chenaghlou
>CS & Math Department
>Faculty of Science
>Tehran University
>Iran
>*/
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Tue, 25 May 2004 18:56:25 -0700
>From: "Clifford Kelley" <[email protected]>
>Subject: Re: [OpenSource_GPS] Re: ??: code tracking
>To: "tebinuma" <[email protected]>,
>	<[email protected]>
>Cc: [email protected]
>Message-ID: <003001c442c4$a7429b80$6401a8c0@cliffkelley>
>Content-Type: text/plain;	charset="iso-8859-1"
>
>Actually the position fix is not affected by this.  It simply appears
>to be an additional clock bias.
>
>Cliff
>----- Original Message -----
>From: "tebinuma" <[email protected]>
>To: <[email protected]>
>Cc: <[email protected]>
>Sent: Tuesday, May 25, 2004 5:57 AM
>Subject: [OpenSource_GPS] Re: ??: code tracking
>
>
> > Yes, you are right. However, the receiver can still
> > give you accurate position solutions with 1/4 chip
> > offset in time estimates. As far as it stationary
> > or moving slowly, it doesn't really cause any problem.
> >
> > Tak
> >
> > --- [email protected] wrote:
> > >
> > >     Thank you,Cliff,
> > >
> > >              I'd like to continue the question:
> > >               Since  The prompt arm looks like a
> > > late arm thus the  loop will lock 1/4 chip early of
> > > the "real" code phase
> > >               then when we calculate transmit time
> > > from code phase,we should subtract 1/4 chip from the
> > > code phase we get from GP2021.
> > >                Right?
> > >
> > >
> > >    Zhu Di
> > >
> > >
> > > -----????-----
> > > ???: Clifford Kelley [mailto:[email protected]]
> > > ????: 2004?5?21? 12:40
> > > ???: Di Zhu (Beijing); [email protected]
> > > ??: Re: code tracking
> > >
> > >
> > > Dear Zhu Di,
> > >
> > > You will notice in chan_allocate() and in
> > > cold_allocate()
> > > this statement:
> > >
> > >       ch_cntl(ch,prn_code[prnn]|0xa000);
> > >
> > >
> > > 0xa000 sets the high order bits as    15  14  13  12
> > >  11  10
> > >
> > >    1    0    1    0
> > > 0    0
> > >
> > > bit 15 sets it for GPS
> > > bits 14 & 13 set the track select to late code
> > > bit 12 sets the update mode
> > > bit 11 sets the code to on
> > > bit 10 sets the source as sign0 and mag0
> > >
> > > So the difference between prompt and late, not
> > > dithering.
> > >
> > >
> > > I hope this helps,
> > >
> > > Cliff
> > >
> > > ----- Original Message -----
> > > From: <[email protected]>
> > > To: <[email protected]>; <[email protected]>
> > > Sent: Thursday, May 20, 2004 9:00 PM
> > > Subject: ??: code tracking
> > >
> > >
> > >
> > >       Hi,Tek and Cliff:
> > >
> > >            sorry,I still cann't understand why
> > > that's a early-minuts-late
> > > discriminator
> > >
> > >            I understand it in this way :
> > >            the tracking arm is set to dithering
> > > mode, It will output
> > > accumulated data as : 1/2 chip early correlation,1/2
> > > chip late
> > > correlation,1/2 chip early corrlation,.....and son
> > > on
> > >           the prompt arm will output accumulated
> > > data: prompt
> > > corrlation,prompt correlation,prompt
> > > correlation....and so on.
> > >          Then,we use "dreq=
> > > trk_code_k*(prompt_mag-dith_mag)"
> > >           we get
> > > dfreq=trk_code_k*(rss(prompt,prompt,prompt...
> > > )-rss(early
> > > +late+early+late,... ) );
> > >           so, I cann't see it's means
> > > early-minus-late.
> > >
> > >           pls give me a help!
> > >           Thanks!
> > >
> > >         Zhu Di
> > >
> > >
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Friends.  Fun.  Try the all-new Yahoo! Messenger.
> > http://messenger.yahoo.com/
> >
> > _______________________________________________
> > opensource_gps mailing list
> > [email protected]
> > http://lists.psas.pdx.edu/cgi-bin/mailman/listinfo/opensource_gps
> >
>
>
>
>------------------------------
>
>Message: 3
>Date: Wed, 26 May 2004 16:06:39 +0430
>From: "Behzad Chenaghlou" <[email protected]>
>Subject: [OpenSource_GPS] A question!!!
>	(OpenSourceGPS,ogs,frame_ready)
>To: [email protected]
>Message-ID: <[email protected]>
>
>Hi everybody
>I got a problem in ogs,( and the base of it osgps)
>
>In function main of OpenSourceGPS  it checks channels frame_ready to see
>if it is one or not,
>In function pream of  OpenSourceGPS it checks channels t_count to see if
>it is 1500 or not,
>In function ch_track of  OpenSourceGPS we call pream:
>void ch_track(char ch)
>{
>          .
>          .
>          .
>	 pream(ch,chan[ch].bit);   // see if we can find the preamble
>	 chan[ch].message[chan[ch].t_count]=chan[ch].bit;
>	 chan[ch].t_count++;
>          .
>          if (chan[ch].t_count==1500)
>         {
>       	     chan[ch].n_frame++;
>	    chan[ch].t_count=0;
>        }
>         .
>         .
>}
>
>Looking to the above code carefully It seems that it never calls pream
>function with t_count==1500, but as I mentioned, in pream we check if
>t_count equals 1500 to set the frame_ready variable(wich it never 
happens!!!).
>
>The question is when the frame_ready will be set?
>or better to say when the navmess function will be called?
>(The exact problem  is in ogs).
>
>best regards
>Behzad Chenaghlou
>
>
>
>
>------------------------------
>
>_______________________________________________
>opensource_gps mailing list
>[email protected]
>http://lists.psas.pdx.edu/cgi-bin/mailman/listinfo/opensource_gps
>
>
>End of opensource_gps Digest, Vol 11, Issue 7
>*********************************************

_________________________________________________________________
浜ㄤ涓澶х靛欢绯荤 MSN Hotmail  http://www.hotmail.com