Re: (no subject)
zbyao <[email protected]> Mon, 18 Aug 2008 10:13:42 +0800
| Newsgroups | gmane.comp.hardware.gps.opensource |
|---|---|
| Message-ID | <[email protected]> |
--===============7596741995246955872==
Content-Type: multipart/alternative;
boundary="----=_Part_27094_11020669.1219025622687"
------=_Part_27094_11020669.1219025622687
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Dear Mr. Cliff,
Thank you very much for your so quickly responses!
Maybe my* explanation* is not clear enough, and my poor English even let you
misunderstand my meaning. Let me try again:
In my FPGA, of course, the correlator is cleared by 1ms when PRN counter
rolls over to 0, and is stored to a temporary register every 1ms. But the
bit status in astat register of FPGA is as follows:
|<------0.505ms--------->|<------0.505ms--------->|<------0.505ms--------->|<------0.505ms--------->|
___________________ ___________________
___|
|_________________| |__________________
When the bit is high level, the ch_pull_in() and ch_track() function will be
executed, that is, once every 0.505ms * 2. This violates your rule: less
than 1ms. Am I right?
According to your rule, the high limit of ch_track() function period is 1ms.
What about the lower limit? If the ch_track() function is executed every
0.3ms, I think the navigation message must be wrong! So, there must exist a
lower limit.
Briefly, what are the high and low limits of ch_pull_in() and ch_track()
function periods?
Looking forward your reply,
Best regards,
Henry
2008/8/18 Clifford Kelley <[email protected]>
> Henry,
>
> I think that is part of your problem. The correlator results should be
> cleared evey 1ms when the PRN counter rolls over to 0. But, only after the
> results have been dumped to a temporary register and the appropriate bit in
> astat has been set indicating it is waiting to be read by the software.
>
> Best regards,
>
> Cliff
>
>
> -----Original Message-----
> From: zbyao
> Sent: Aug 17, 2008 7:34 AM
> To: Clifford Kelley
> Subject: Re: [OpenSource_GPS] (no subject)
>
> According to GP2021 datasheet, the ACCUM_INT period is 0.50505ms. So, in my
> FPGA, it is 0.505ms also, which is the intterrupt period. But I reset the
> correlator results every 0.505ms in FPGA, which means in the software, the
> ch_pull_in() and ch_track() function will be executed every
> 0.505ms*2=1.01ms, more than 1ms. Is this wrong? Will this problem cause the
> pream() function to parity check fail?
>
> In OSGPS, as you said, the ch_pull_in() and ch_track() function will be
> exectued every less 1ms? Is this right?
>
> But in ch_track() function, the ms_count variable will be incremented by 1
> when executing ch_track() function, which means the software ms_count
> variable will be incremented every less than 1ms. And this will lead to
> error navigation message, also leading to pream() function's parity check
> failure! For example, if the ch_track() will be exectued every 0.8ms, then
> the ms_count error is 0.2ms. Therefore, every 1bit time period (20ms), the
> error will be 4ms! And every 1 subframe (6s), the error will be 4*300ms!
>
> Could you supply more details about this problem?
>
> Best regards,
> Henry
>
> 2008/8/17 Clifford Kelley <[email protected]>
>
>> I don't know about your FPGA but astat indicates which channels have
>> dumped correlator results since the last time it was read. Normally it is
>> read after an interrupt occurs which should be occuring in less than 1 ms
>> intervals.
>>
>> Best regards,
>>
>> Cliff
>>
>>
>> The OpenSource GPS software is free, therefore the author makes no warranty or
> representation either express or implied with respect to this software or
> communication including its quality, merchantability, or fitness for a particular purpose.
> In no event will the author be liable for direct, indirect, special,
> incidental, or consequential damages arising out of the use or inability to use this
> software or communication even if the author has been advised of the possibility
> of such damages.
>
>
------=_Part_27094_11020669.1219025622687
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div dir="ltr">Dear Mr. Cliff,<br><br>Thank you very much for your so quickly responses!<br><br>Maybe my<b> <span style="font-weight: normal;">explanation</span></b> is not clear enough, and my poor English even let you misunderstand my meaning. Let me try again:<br>
<br>In my FPGA, of course, the correlator is cleared by 1ms when PRN counter rolls over to 0, and is stored to a temporary register every 1ms. But the bit status in astat register of FPGA is as follows:<br><br> |<------0.505ms--------->|<------0.505ms--------->|<------0.505ms--------->|<------0.505ms--------->|<br>
___________________ ___________________<br>
___| |_________________| |__________________<br><br>When the bit is high level, the ch_pull_in() and ch_track() function will be executed, that is, once every 0.505ms * 2. This violates your rule: less than 1ms. Am I right? <br>
<br>According to your rule, the high limit of ch_track() function period is 1ms. What about the lower limit? If the ch_track() function is executed every 0.3ms, I think the navigation message must be wrong! So, there must exist a lower limit.<br>
<br>Briefly, what are the high and low limits of ch_pull_in() and ch_track() function periods?<br><br>Looking forward your reply,<br>Best regards,<br><br>Henry<br><br><br><div class="gmail_quote">2008/8/18 Clifford Kelley <span dir="ltr"><<a href="mailto:[email protected]">[email protected]</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<p>Henry,</p>
<p>I think that is part of your problem. The correlator results should be cleared evey 1ms when the PRN counter rolls over to 0. But, only after the results have been dumped to a temporary register and the appropriate bit in astat has been set indicating it is waiting to be read by the software.</p>
<p>Best regards,</p>
<p>Cliff<br><br><br></p>
<blockquote style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 0px;">-----Original Message----- <br>From: zbyao <br>Sent: Aug 17, 2008 7:34 AM <br>To: Clifford Kelley <br>Subject: Re: [OpenSource_GPS] (no subject) <br>
<br>
<div dir="ltr">According to GP2021 datasheet, the ACCUM_INT period is 0.50505ms. So, in my FPGA, it is 0.505ms also, which is the intterrupt period. But I reset the correlator results every 0.505ms in FPGA, which means in the software, the ch_pull_in() and ch_track() function will be executed every 0.505ms*2=1.01ms, more than 1ms. Is this wrong? Will this problem cause the pream() function to parity check fail?<br>
<br>In OSGPS, as you said, the ch_pull_in() and ch_track() function will be exectued every less 1ms? Is this right?<br><br>But in ch_track() function, the ms_count variable will be incremented by 1 when executing ch_track() function, which means the software ms_count variable will be incremented every less than 1ms. And this will lead to error navigation message, also leading to pream() function's parity check failure! For example, if the ch_track() will be exectued every 0.8ms, then the ms_count error is 0.2ms. Therefore, every 1bit time period (20ms), the error will be 4ms! And every 1 subframe (6s), the error will be 4*300ms!<br>
<br>Could you supply more details about this problem? <br><br>Best regards,<br>Henry<br><br>
<div class="gmail_quote">2008/8/17 Clifford Kelley <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<p>I don't know about your FPGA but astat indicates which channels have dumped correlator results since the last time it was read. Normally it is read after an interrupt occurs which should be occuring in less than 1 ms intervals.</p>
<p>Best regards,</p>
<p>Cliff<br><br><br></p></div></blockquote></div></div></blockquote></div><pre>The OpenSource GPS software is free, therefore the author makes no warranty or
representation either express or implied with respect to this software or
communication including its quality, merchantability, or fitness for a particular purpose.
In no event will the author be liable for direct, indirect, special,
incidental, or consequential damages arising out of the use or inability to use this
software or communication even if the author has been advised of the possibility
of such damages.</pre>
</blockquote></div><br></div>
------=_Part_27094_11020669.1219025622687--
--===============7596741995246955872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
opensource_gps mailing list
[email protected]
http://lists.psas.pdx.edu/cgi-bin/mailman/listinfo/opensource_gps
--===============7596741995246955872==--