PRN-Nummer in TLE-Dateien ist die gleiche wie in RINEX-Dateien? (in GPS-Konstellation)

Ich möchte die mit Pyephem- und TLE -Dateien berechnete Position mit RINEX- Dateien und der GPSTK- Bibliothek an einem bestimmten Datum und einer bestimmten Uhrzeit vergleichen , aber ich habe nicht die Gewissheit, ob der Name des Satelliten "PRN ##" in beiden Dateien gleich ist ( TLE und RINEX)?

zB in Celestrak (TLE-Datei) für eine GPS-Konstellation lautet die ID oder der Name des Satelliten:

GPS BIIF-1 (PRN 25)
1 26690C 01004A 17096.69312500 -.00000000 00000-0 00000-0 0 966 2 26690 53.0252 160.8176 0181123 256.0966 20.3055 20.3285

aber in den RINEX-Dateien ist nur ein Buchstabe mit einer Zahl verbunden, wie folgt:

17 01 12 00 00 0,0000000 0 21G05G16G20G21 G25 G26G27G29G31R01R02R09 R15R16R17R18R19E01E26S20S36

Dabei steht der Buchstabe für die Konstellation G für die GPS- Konstellation und R für die GLONASS- Konstellation, S für SBAS usw. Neben dem Buchstaben steht eine Zahl, z. B. G25 , die Nummer dieses Satelliten ist 25 für die RINEX-Datei.

Ich habe mit GPS-Konstellation gearbeitet. Ich teste mit etwas Code in Python, aber ich bin mir nicht sicher, ob die PRN 25 mit G25 identisch ist?, weil die Berechnung der Höhe des Satelliten mit der ID 25 an einem ganzen Tag in der Zeit, die die RINEX-Datei zeigt, unterschiedlich ist Vergleich mit TLE-Dateien ... oder vielleicht stimmt etwas in meinem Code nicht.

obsHeader, obsData = gpstk.readRinex3Obs(obsfile)
navHeader, navData = gpstk.readRinex3Nav(navfile)
# setup ephemeris store to look for satellite positions
bcestore = gpstk.GPSEphemerisStore()
for navDataObj in navData:
    ephem = navDataObj.toGPSEphemeris()
    bcestore.addEphemeris(ephem)
bcestore.SearchNear()
navData.close()
#look each satellite
for obsObject in obsData: #round the data
    for satID, datumList in obsObject.obs.iteritems():
        if satID.systemGPS == satID.system and satID.id == NumSatellite:
            time=obsObject.time #satellite time from the observation
            CivilTime = gpstk.CivilTime(obsObject.time)
            #break
            eph   = bcestore.findEphemeris(satID, obsObject.time)
            svXvt = eph.svXvt(obsObject.time)
            elev = obsHeader.antennaPosition.elvAngle(svXvt.getPos())
            azim    = obsHeader.antennaPosition.azAngle(svXvt.getPos())
            
            SecondsTime.append(obsObject.time.getSecondOfDay())
            TimesSatRin.append(CivilTime)
            AziSatRin.append(azim)
            ElevSatRin.append(elev)
#for each observation day.
DateTimeRinex = CivilTime2datetime(TimesSatRin)
for t in DateTimeRinex:
    #for each Time of the rinex (for the specific Satellite)
    print 'next time: ', t

    names,elevs,azs,types = GetPositionELAZ(t,Longitude_obs,Latitude_obs,1) #just GPS with TLE files
    print names
    for i in range (0,len(names)):
        number = int(filter(str.isdigit, names[i]))
        #print number,' number sat of the TLE'
        if number == NumSatellite:
            print 'GOT',number,' number sat of the TLE'
            TimeTLE.append(t)
            ElevTLE.append(elevs)
            AzimTLE.append(azs)

Die Position (lon, Lat) ist die gleiche wie die der Bodenstation des RINEX-Dateispeichers. Danke.

UPDATE 1:
Ich teste mit meinem Code, ein Fahrzeug nach dem anderen, und ich kann den Vergleich der Höhen jedes Satelliten über den Tag hinweg sehen. Für RINEX-Dateien versuche ich es mit 4 Tagen, Tag des Jahres 101, 100, 80 und 10. und für diese Tage immer die TLS PRN 10 , die Ergebnisse sind ähnlich wie bei RINEX PRN 12 ; Ich sagte ähnlich, weil es nicht die gleichen Ergebnisse sind. Ich überprüfe noch.

20. April

20. april

19. April

19. April

21. März

21. März

10. Januar

10. Januar

Anscheinend existiert neben jeder PRN-ID für TLE eine PRN-ID für RINEX, in diesem Fall RINEX PRN 12 = TLE PRN 10. Dies ist jedoch nicht die genaue Antwort, daher lasse ich die Frage offen

UPDATE 2:

Die Positionsberechnung mit TLE ist sehr genau. aber ich habe einen Fehler bekommen, ich habe eine Position in Längengrad/Breitengrad erhalten, aber es war eine falsche Position, sicher müssen Sie die Position zum Vergleichen von der RINEX-Datei (der Beobachtungsdatei) in der Kopfzeile nehmen; Die Datei hat die Position in X, Y, Z, daher ist eine Konvertierung in die Position Längengrad-Breitengrad erforderlich.Geben Sie hier die Bildbeschreibung ein

um den Längengrad-Breitengrad zu erhalten:

def Get_latitude(x, y, z):
    #radius earth
    r = 6371000.
    return np.arcsin(z/r)*(180/np.pi)

def Get_longitude(x, y, z):
    #radius earth
    r = 6371000.
    if (x > 0):
        return np.arctan(y/x)*(180./np.pi)
    elif y > 0:
        return np.arctan(y/x)*(180./np.pi) + 180.
    else:
        return np.arctan(y/x)*(180./np.pi) - 180.
Ich bin mir nicht sicher, ob ich das Problem richtig verstanden habe, aber die PRN-Nummer ist einem GPS-Satelliten zugeordnet, daher sollte sie sich nicht zwischen verschiedenen Quellen ändern. Was ist der Unterschied, von dem du sprichst?
Die TLS-Datei-ID für jeden Satelliten ist z. B. GPS BIIRM-3 (PRN 12) und in der RINEX-Datei ist z. B. G12 , ich versuche, denselben Satelliten zu vergleichen, z der Test, sind nicht die gleichen Satelliten (PRN12 und G12) also, was ist der gleiche Satellit in TLE-Dateien und RINEX-Dateien? (oder vielleicht ist mein Test falsch)
Nebenbemerkung: Skyfield ist ein weiteres Python-Paket, das einige Funktionen hat, die sich mit pyephem überschneiden. Beide werden von derselben Person gewartet, aber in Zukunft könnte Skyfield für die Satelliten- und Sonnensystem-Raumfahrt nützlicher werden, da es direkt auf den JPL-Ephemeriden aufgebaut ist, während pyephem viele spezialisierte Berechnungen durchführt, aber nicht aus den JPL-Ephemeriden schöpft.
Danke @uhoh, ich teste gerade Skyfield, das ich nicht kannte, und es ist so interessant. Im Moment vergleiche ich die Position des Satelliten in Azimut und Elevation, also funktionieren beide Bibliotheken für mich, aber ich sehe, dass Skyfield auch TLE verwendet. ist es falsch, die RINEX-Dateien mit den TLE-Dateien zu einem bestimmten Datum zu vergleichen?
Es gibt viele Objekte im Orbit und nur sehr wenige Menschen behalten alle ihre Namen im Kopf. Um Ihre Chancen auf eine Antwort zu verbessern, posten Sie konkrete Beispiele für das, worüber Sie sprechen. Ich habe in einem Satcat-Download von CelesTrak nachgesehen und sehe "BIIRM" nirgendwo. Was ist eine „TLS-Datei-ID“? Bitte ändern Sie Ihre Frage und fügen Sie klare, spezifische Beispiele für das hinzu, wovon Sie sprechen. Erwarten Sie nicht, dass die Leute für Sie nach einer Antwort suchen. Was haben Sie sich bisher angesehen, um die Antwort zu finden? Ich denke, das ist die Art von Dingen, auf die sich @VolkanOzcan möglicherweise bezogen hat.
PRNs werden periodisch neu zugewiesen, sodass ein bestimmter SV im Laufe seines Lebens mehrere unterschiedliche PRNs haben kann. Es ist durchaus möglich, dass Celestrak oder sein Datenanbieter nicht vollständig über die PRN-Änderungen informiert sind.

Antworten (1)

Ich denke, was hier vor sich geht, ist im Grunde dasselbe, was in dieser Frage besprochen wurde, wobei die beiden Antworten "sie verwenden unterschiedliche Koordinatensysteme" und "sie bedeuten unterschiedliche Dinge mit denselben Elementnamen" lauten. Selbst wenn das OP die Framerotation korrekt hinbekommen hat, überraschen mich Unterschiede in dieser Größenordnung überhaupt nicht. Aus einem Grund definieren die Spezifikationen für GPS und für TLE unterschiedliche Gleichungen zur Modellierung des kurzzeitigen, nicht elliptischen Verhaltens von Umlaufbahnen, so dass beim Vergleich der Ergebnisse im Detail über einen bestimmten Zeitraum hinweg die Formen der Kurven nur zu kurz kommen etwas anders sein.

Das Einzigartige an dieser Frage ist, wie die Satelliten-ID (naja, pseudozufällige Rauschsequenz-ID) ins Bild kommt. Hier vermute ich nur den Code des OP, aber was meiner Meinung nach passieren könnte, ist, dass es viele GPS-Satelliten gibt und sie alle sehr ähnliche Umlaufbahnen haben. Dies bedeutet wahrscheinlich, dass Sie, wenn Sie die Rahmendrehung nicht richtig handhaben und sich genügend Daten ansehen, mit Glück einige Beispiele finden, bei denen Sie systematisch an der falschen Stelle nach dem gesuchten Satelliten gesucht haben, aber wenn Sie Wenn Sie dort nachgesehen haben, haben Sie tatsächlich einen anderen Satelliten der gleichen Konstellation an ziemlich genau der Stelle gefunden, an der Sie gesucht haben.