A Satellite Navigation and Global Positioing Systems forum. Sat Nav Banter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » Sat Nav Banter forum » GPS and Sat Nav Newsgroups » sci.geo.satellite-nav (Global Satellite Navigation)
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

sci.geo.satellite-nav (Global Satellite Navigation) (sci.geo.satellite-nav) Discussion of global navigation satellite systems (GNSS). Topics include the technical aspects of GNSS operation, user experiences in the use of GNSS, information regarding GNSS products and discussion of GNSS policy (such as GPS selective availability).

Bits for PRN code



 
 
Thread Tools Display Modes
  #1  
Old September 14th 15, 10:59 PM posted to sci.geo.satellite-nav
[email protected]
external usenet poster
 
Posts: 1
Default Bits for PRN code

What is the maximum number of bits for a PRN code that is 1023 bit maximum but maintains sufficient orthogonality with other PRNs to avoid signal degradation due to interference with the other codes?

I know there are about 210 PRNs in the registry, but I'm wondering if there's a larger superset where some unassigned, but used, secretive PRNs lurk?

Michael Sabino
AC9HH
  #3  
Old September 15th 15, 05:49 AM posted to sci.geo.satellite-nav
Terje Mathisen[_3_]
external usenet poster
 
Posts: 25
Default Bits for PRN code

Alan Browne wrote:
On 2015-09-14 17:59, wrote:
What is the maximum number of bits for a PRN code that is 1023 bit
maximum but maintains sufficient orthogonality with other PRNs to
avoid signal degradation due to interference with the other codes?

I know there are about 210 PRNs in the registry, but I'm wondering if
there's a larger superset where some unassigned, but used, secretive
PRNs lurk?

Michael Sabino AC9HH



42


42 is actually a pretty good estimate. :-)

Okay.

I don't know but assuming 210 is a valid number (I thought it was much
less) you have to wonder how much more can be added without the
interference rate increasing - esp. in high noise environments.


As you say, each time you increase the number of simultaneously visible
PRN codes, you also increase the interference rates, the original 30+
bit patterns were selected to give maximum decorrelation between any
given pair of them, but you could obviously partially reuse that space
for sats that are in opposite orbits, so that they would never be
simultaneously visible. (You can't use exactly the same codes because
that would make cold starts impossible!)

The widely separated orbits requirement also implies widely different
doppler offsets, which also would help to maintain lock to two sats with
fairly similar codes.

The issue is once again that a cold start would require minimum
correlation not just with all other visible sats at baseline doppler
frequency but also on all possible relative doppler offsets.

Why would "secretive" be an issue? Y code is there in plain sight and
encrypted far beyond a decryption effort within the 7 day truncated
sequence. You can use it in a codeless receiver, but that's limited to
surveying and other localized high precision apps.


Right, there's absolutely nothing secret here. It is almost trivial to
model the correlation between any given pair of codes, just run a
convolve of one over the other, while also modifying the relative
doppler offset.

Doing the same for all the codes takes a bit more work, particularly if
you are looking for a globally optimum set of new codes to add to the
current constallations.

Terje

--
- Terje.Mathisen at tmsw.no
"almost all programming can be viewed as an exercise in caching"
  #4  
Old September 25th 15, 06:02 PM posted to sci.geo.satellite-nav
Alan Browne
external usenet poster
 
Posts: 1,339
Default Bits for PRN code

On 2015-09-15 00:49, Terje Mathisen wrote:
Alan Browne wrote:
On 2015-09-14 17:59, wrote:
What is the maximum number of bits for a PRN code that is 1023 bit
maximum but maintains sufficient orthogonality with other PRNs to
avoid signal degradation due to interference with the other codes?

I know there are about 210 PRNs in the registry, but I'm wondering if
there's a larger superset where some unassigned, but used, secretive
PRNs lurk?

Michael Sabino AC9HH



42


42 is actually a pretty good estimate. :-)


For most hitchhikers, anyway.

I have seen a higher number somewhere - around 70 - 100 I think, but I
can't seem to locate it. To use such a number certain "accommodations"
were proposed, however.


Okay.

I don't know but assuming 210 is a valid number (I thought it was much
less) you have to wonder how much more can be added without the
interference rate increasing - esp. in high noise environments.


As you say, each time you increase the number of simultaneously visible
PRN codes, you also increase the interference rates, the original 30+
bit patterns were selected to give maximum decorrelation between any
given pair of them, but you could obviously partially reuse that space
for sats that are in opposite orbits, so that they would never be
simultaneously visible. (You can't use exactly the same codes because
that would make cold starts impossible!)


You could use some hitherto unused bit somewhere (or even subframe 4 of
page 17 (ICD-200 p.117)), [or even the LSbit of some over precise
parameter in the Almanac[1]] to enhance the identity of a given
satellite and thence maintain two almanac/ephemeris sets per PRN. A
little messy to be sure ... the very definition of kludge.

[1]: Such as ω in the Almanac spec'd to 24 bits of a semi-circle.

So you'd have PRN X and PRN X' sets of Almanac and ephemeris.

The widely separated orbits requirement also implies widely different
doppler offsets, which also would help to maintain lock to two sats with
fairly similar codes.


Yep.

The issue is once again that a cold start would require minimum
correlation not just with all other visible sats at baseline doppler
frequency but also on all possible relative doppler offsets.

Why would "secretive" be an issue? Y code is there in plain sight and
encrypted far beyond a decryption effort within the 7 day truncated
sequence. You can use it in a codeless receiver, but that's limited to
surveying and other localized high precision apps.


Right, there's absolutely nothing secret here. It is almost trivial to
model the correlation between any given pair of codes, just run a
convolve of one over the other, while also modifying the relative
doppler offset.

Doing the same for all the codes takes a bit more work, particularly if
you are looking for a globally optimum set of new codes to add to the
current constallations.


Better to have new modulation schemes perhaps.

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 01:55 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.SEO by vBSEO 2.4.0
Copyright 2004-2018 Sat Nav Banter.
The comments are property of their posters.