GPS per Cubesats: 8 km / sec è troppo veloce per i chip di consumo?


10

I satelliti in orbita terrestre bassa si stanno avvicinando a 8 km / sec. La maggior parte dei chip GPS di livello consumer invocano ancora i limiti CoCom di 1000 nodi, circa 514 m / s. I limiti di CoCom sono limiti volontari per le esportazioni di cui puoi leggere di più in questa domanda e risposta e in questa domanda e risposta e altrove.

Per questa domanda, supponiamo che siano limiti numerici nella sezione di output del firmware. Il chip deve effettivamente calcolare la velocità (e l'altitudine) prima di poter decidere se il limite viene superato, quindi presentare la soluzione all'uscita o bloccarla.

A 8000 m / s lo spostamento del doppler a 2 GHz è di circa 0,05 MHz, una piccola frazione della larghezza naturale del segnale a causa della sua modulazione.

Esistono diverse aziende che vendono unità GPS per cubesat e sono costose (da centinaia a migliaia di dollari) e probabilmente valgono ogni centesimo perché (almeno alcune di esse) sono progettate per applicazioni satellitari e testate nello spazio.

Ignorando l'implementazione dei limiti di CoCom e tutti gli altri problemi di funzionamento nello spazio oltre alla velocità , ci sono dei motivi per cui un moderno chip GPS con una velocità massima di 500 m / s non sarebbe in grado di funzionare a 8000 m / s? Se sì, quali sono?

nota: 8000 m / s diviso per c (3E + 08 m / s) fornisce circa 27 ppm di espansione / compressione delle sequenze ricevute. Ciò potrebbe influire su alcune implementazioni di correlazione (sia hardware che software).


3
La prima ragione che mi viene in mente è che non ha senso nemmeno testare, figuriamoci progettare per queste velocità, quindi lavorare lì è pura fortuna o coincidenza.
PlasmaHH,

2
Sono con PlasmaHH su questo. Se devo rilasciare un prodotto che il 99,9% dei miei clienti utilizzerà a velocità automobilistiche tipiche o inferiori, non vale la pena di provarlo a 8000 km / h anche se mi aspetto che funzioni. Inutile dire che è sciocco inserire specifiche che non sono state testate.
Dmitry Grigoryev,

3
@DmitryGrigoryev Il test GPS viene solitamente eseguito con un simulatore di segnale: la velocità è solo un numero inserito. Non costa controllare e i buoni ingegneri vorranno sempre conoscere il limite di prestazioni di un progetto. Ma per favore, la mia domanda che mi chiede quale parte della funzione GPS sarà probabilmente la prima a fallire ad alta velocità, non "cosa faresti se tu fossi un ingegnere del prodotto".
uhoh

2
@uhoh Forse sono testati a 8000 km / h usando un simulatore. Tuttavia, non inserirò quel numero nelle specifiche senza testare la cosa reale. Ho visto un sacco di roba lavorare su un simulatore o un banco di prova, per poi fallire in modo spettacolare nella pratica.
Dmitry Grigoryev il

1
@DmitryGrigoryev possiamo allontanarci da quello che faresti se tu ...
uhoh

Risposte:


6

Non consiglierei di utilizzare una soluzione GPS integrata (contenente MCU e firmware a sorgente chiuso) per un'applicazione satellitare. Esistono diversi motivi per cui questo potrebbe non funzionare:

  1. Il piano di frequenza frontend potrebbe essere ottimizzato per un intervallo doppler limitato. Tipicamente, il frontend RF mescolerà il segnale a un IF inferiore a 10 MHz (IF più alto richiederà una frequenza di campionamento più alta e consumerà più energia). Questo IF non è scelto arbitrariamente! Il quoziente IF / campionatore deve essere non armonico per l'intera gamma del doppler per evitare toni spuri dovuti a errori di troncamento a / d nel segnale campionato. È possibile osservare effetti di battito che rendono il segnale inutilizzabile ad alcune velocità doppler.
  2. Il correlatore del dominio digitale deve riprodurre una replica del corriere e il codice C / A alla velocità corretta, inclusi gli effetti doppler. Utilizza DCO (oscillatori controllati digitali) per stimolare la generazione di portatori e codici, che sono sintonizzati tramite i registri di configurazione dall'MCU. L'ampiezza di bit di questi registri può essere limitata all'intervallo doppler previsto per un ricevitore a terra, rendendo impossibile sintonizzare il canale sul segnale se si viaggia troppo velocemente.
  3. Il firmware dovrà effettuare un'acquisizione a freddo se non è disponibile alcuna stima di posizione / tempo. Cercherà bin di frequenza doppler e fasi di codice per trovare un segnale. L'intervallo di ricerca sarà limitato all'intervallo previsto per un utente a terra.
  4. Il firmware in genere utilizzerà il filtro kalman per le soluzioni di posizione. Ciò comporta un modello di posizione / velocità / accelerazione del ricevitore. Sebbene l'accelerazione non costituisca una preoccupazione per un satellite, il modello fallirà per la velocità, se il firmware non è adattato per l'uso in orbita.

Tutti questi problemi possono essere risolti se si utilizza un frontend e un correlatore liberamente programmabili con un firmware personalizzato. Potresti guardare Piksy .


Per il punto 1. (larghezza di banda front-end) la larghezza di banda originale del segnale è molto più ampia dello spostamento del doppler - considerare il caso peggiore circa 10 km / sec di velocità relativa vs 3E + 05 km / sec di velocità della luce sarà di circa 50 kHz. Ma 2, 3, 4 sembrano tutti potenziali interruttori per chip e firmware ottimizzati per il consumatore.
uhoh,

2
@uhoh: sono d'accordo con il tuo argomento sulla larghezza di banda, ma il punto 1 non riguarda la larghezza di banda. Avrei dovuto spiegare meglio. Se la frequenza di campionamento è 16.368.000 / se il segnale in IF è centrato a 4.092.000 Hz e hai un a / d con una risoluzione di 4 bit, allora hai un problema con il battito. Ogni errore di troncamento dei campioni andrà nella stessa direzione. C'è un sacco di brutti punti (zero IF è un altro brutto, ma ogni armonica è cattiva). Ti consigliamo di mantenere la distanza (dipende dal periodo di integrazione) a questi punti per qualsiasi doppler previsto.
Andreas,

Ottimo, grazie mille per questa risposta! Mi dà molte informazioni su ciò che sta succedendo. Ancora non capisco l'errore di pestaggio / troncamento, ma posso andare a leggere un po 'e magari fare una domanda in seguito. Ho una domanda ACD diversa relativa agli ADC a tre bit ad alta frequenza (PiSky ha ADC a 3 bit).
uhoh,

1
Ha a che fare con l'S / N dei singoli campioni, il che è davvero negativo. Investire in maggiore precisione presso l'ADC non migliorerà molto le prestazioni complessive del sistema. È un compromesso complicato, cercherò di dare una risposta utile alla tua domanda ALMA.
Andreas,

4

Alcune persone implementano COCOM come un o , altri come un e . Ad ogni modo, per i clienti qualificati nell'ambito EAR o ITAR, i venditori ti venderanno felicemente un'opzione firmware per $$$ che disabilita tale funzionalità. L'hardware è identico.

Al di fuori di questa dura limitazione, diventa un problema di comunicazione RF, insieme alla progettazione dell'hardware per tollerare gli effetti delle radiazioni. Il tuo Eb / N0 sarà probabilmente un po 'migliore dato che sei (letteralmente) più vicino agli SV ed evitando la perdita del percorso atmosferico, ma anche i tuoi circuiti di ricezione dovranno tollerare una notevole quantità di Doppler.

Tuttavia, non è solo la posizione a cui CubeSat è interessato: il tempo GPS è un bene di dati preziosi che aiuta un satellite a capire dove si trova, dato un TLE. Anche se il ricevitore rifiuta di darti una posizione a causa di COCOM, se dà il tempo, può valerne la pena.


Cosa significano "Eb / N0" e "SV"? Sai con certezza se viene segnalato il tempo effettivo quando le coordinate spaziali sono bloccate o intendi solo il segnale 1pps? Si prega di notare che ho specificato: "Ignorare l'implementazione dei limiti di CoCom e tutte le altre questioni operative nello spazio oltre alla velocità .."
uhoh

Due anni fa i satelliti sono stati riclassificati come "non munizioni", quindi ITAR non è più stato applicato, ma ora EAR si applica come dici tu. Ci sono ancora MTCR e l' accordo di Wassenaar anche e forse anche di più!
uhoh

3
@uhoh suppongo che i termini siano Eb / N0 => rapporto segnale-rumore e SV => veicoli spaziali (i satelliti GPS effettivi)
user2943160

@ user2943160 Grazie, ha senso. Cerco sempre di imparare cose nuove - se Eb è un termine specifico, mi piacerebbe impararlo.
uhoh

Recentemente ho fatto molte cose di comunicazione, Eb / No è ​​solo il SNR "normalizzato", o SNR per bit. Probabilmente sarebbe stato più accurato utilizzare solo SNR o RSSI in quella risposta. Aneddoticamente, ho sentito che alcuni chipset (credo SiRF) riporteranno comunque il tempo ma ti congeleranno fuori posizione, ma non l'ho confermato personalmente.
Krunal Desai,

2

Se questo documento sull'architettura GPS di esempio è rappresentativo, i chip sono costituiti da un front-end RF, correlatori hardware nel dominio digitale e tutta la decodifica effettiva del segnale viene eseguita nel software.

Nel qual caso l'unico problema probabile è il doppler. Il software potrebbe scartare valori "eccezionali", ma è necessario sostituire o modificare il firmware comunque se si desidera bypassare i limiti di CoCom.

Una domanda più interessante è se è possibile prendere in prestito un simulatore GPS che può essere programmato per simulare il caso ad alta velocità. Avrei pensato che sarebbe stato possibile - dopo tutto, come farebbe un produttore a verificare che il proprio dispositivo stia applicando i limiti CoCom?


3
Si noti che anche a 0 km / h si ha a che fare con Doppler, poiché i satelliti si stanno già muovendo a 8000 m / s.
Dmitry Grigoryev,

Mi piace la tua logica! È davvero uno spostamento di tipo (fino a) +/- 60 kHz applicato in modo diverso a ciascun segnale satellitare, buone probabilità che la maggior parte dei simulatori possa farlo. Solo per la cronaca, in realtà non lo sto facendo - lo sto solo chiedendo !
uhoh,

2
No @DmitryGrigoryev ti sbagli sull'8000. Si stanno muovendo molto più lentamente perché sono in orbite molto più alte. Ma hai ragione sul fatto che ci sia un sacco di Doppler oltre al movimento dell'unità GPS. È un buon punto!
uhoh

@uhoh Il mio errore. Il mio commento dovrebbe invece essere di 14.000 km / h.
Dmitry Grigoryev,

5
Questo è molto meno rilevante sul campo, però: la velocità tangenziale all'osservatore non causa il doppler. Tuttavia provoca un piccolo effetto relativistico: physics.stackexchange.com/questions/1061/…
pjc50

2

Dipende molto dall'implementazione. Ad esempio, un ricevitore su cui ho lavorato ha un registro di frequenza NCO portante a punto fisso in ciascun canale del correlatore, con una larghezza di 17 bit. Il valore massimo che può essere memorizzato in questo registro corrisponde a circa 6 km / s e deve anche includere un contributo dall'errore di frequenza di clock del ricevitore. Quindi non sarebbe in grado di tracciare i satelliti la cui portata supera tale limite, che sarebbero parecchi se il ricevitore si muove a velocità orbitali.


1

Cubesats può essere utilizzato con unità GPS commerciali standard che sono inferiori a 1000 $. Il produttore rimuove i limiti, quindi si spera che siano in grado di testarli rimossi. Hanno emulatori GPS o accedono ad essi.

I limiti cocom devono essere rimossi dal produttore e il produttore lo farà solo se è possibile ottenere un'eccezione attraverso il proprio governo. Non sono sicuro del processo, ma so che è possibile almeno negli Stati Uniti. Al di fuori degli Stati Uniti questo potrebbe essere quasi impossibile.

Non conosco la precisione dell'unità GPS, ma ci sono ancora effetti ionosferici che devono essere presi in considerazione, se voli in LEO. Avrai anche bisogno di un discreto sistema ADCS per stimare la posizione della tua astronave


Gli effetti ionosferici non indurrebbero comunque errori sulla scala dei metri o nel caso peggiore decine di metri? A meno che un cubesat non stia facendo cose che richiedono un tempo di millisecondo o un volo di formazione basato su GPS, questo non finirebbe per importare per la maggior parte dei cubesat. È bello ricordare però, grazie!
uhoh,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.