GPS pour Cubesats - est-ce que 8 km / sec est trop rapide pour les puces grand public?


10

Les satellites en orbite terrestre basse se déplacent à près de 8 km / sec. La plupart des puces GPS grand public invoquent toujours les limites CoCom de 1000 nœuds, soit environ 514 m / s. Les limites CoCom sont des limites volontaires pour les exportations que vous pouvez lire plus dans cette question et réponse et cette question et réponse et ailleurs.

Pour cette question, supposons qu'il s'agit de limites numériques dans la section de sortie du firmware. La puce doit réellement calculer la vitesse (et l'altitude) avant de pouvoir décider si la limite est dépassée, puis présenter la solution à la sortie ou la bloquer.

À 8000 m / s, le décalage Doppler à 2 GHz est d'environ 0,05 MHz, une petite fraction de la largeur naturelle du signal en raison de sa modulation.

Il existe plusieurs sociétés qui vendent des unités GPS pour des cubesats, et elles sont chères (des centaines à des milliers de dollars) et valent probablement chaque centime car (au moins certaines d'entre elles) sont conçues pour des applications satellites et testées dans l'espace.

En ignorant la mise en œuvre des limites CoCom et tous les autres problèmes de fonctionnement dans l'espace en plus de la vitesse , y a-t-il des raisons pour lesquelles une puce GPS moderne mouchetée à une vitesse maximale de 500 m / s ne pourrait pas fonctionner à 8000 m / s? Si c'est vrai, que sont-ils?

note: 8000 m / s divisé par c (3E + 08 m / s) donne environ 27 ppm d'expansion / compression des séquences reçues. Cela peut affecter certaines implémentations de corrélation (à la fois au niveau matériel et logiciel).


3
La première raison qui me vient à l'esprit est que cela n'a aucun sens de tester, et encore moins de concevoir pour ces vitesses, donc il n'y a que de la chance ou une coïncidence.
PlasmaHH

2
Je suis avec PlasmaHH sur celui-ci. Si je veux sortir un produit que 99,9% de mes clients utiliseront à des vitesses automobiles typiques ou moins, cela ne vaut pas la peine de le tester à 8000 km / h, même si je m'attends à ce qu'il fonctionne. Inutile de dire qu'il est insensé de mettre dans une spécification quelque chose que vous n'avez pas testé.
Dmitry Grigoryev

3
@DmitryGrigoryev Les tests GPS sont généralement effectués avec un simulateur de signal - la vitesse n'est qu'un nombre entré. La vérification n'est pas coûteuse et les bons ingénieurs voudront toujours connaître la limite de performance d'une conception. Mais s'il vous plaît, ma question demandant quelle partie de la fonction GPS sera probablement la première à échouer à haute vitesse, et non "que feriez-vous si vous étiez ingénieur produit".
uhoh

2
@uhoh Peut-être qu'ils sont testés à 8000 km / h à l'aide d'un simulateur. Pourtant, je ne mettrais pas ce nombre dans la spécification sans tester la vraie chose. J'ai vu beaucoup de choses travailler sur un simulateur ou un banc d'essai, puis échouer de façon spectaculaire dans la pratique.
Dmitry Grigoryev

1
@DmitryGrigoryev pouvons-nous nous éloigner de ce que vous feriez si vous ...
uhoh

Réponses:


6

Je ne conseillerais pas d'utiliser une solution GPS intégrée (contenant MCU et firmware source fermé) pour une application satellite. Il y a plusieurs raisons pour lesquelles cela pourrait ne pas fonctionner:

  1. Le plan de fréquence frontal peut être optimisé pour une plage Doppler limitée. En règle générale, l'interface RF mixera le signal à un FI inférieur à 10 MHz (un FI plus élevé nécessitera un taux d'échantillonnage plus élevé et consommera plus d'énergie). Cette FI n'est pas choisie arbitrairement! Le quotient IF / échantillonneur doit être non harmonique pour toute la plage de doppler afin d'éviter les tonalités parasites dues à des erreurs de troncature a / d dans le signal échantillonné. Vous pouvez observer des effets de battement qui rendent le signal inutilisable à certains taux de doppler.
  2. Le corrélateur de domaine numérique doit reproduire une réplique de la porteuse et du code C / A au taux correct, y compris les effets doppler. Il utilise des DCO (oscillateurs contrôlés numériques) pour stimuler la génération de porteuses et de codes, qui sont réglés via les registres de configuration du MCU. La largeur de bits de ces registres peut être limitée à la plage Doppler attendue pour un récepteur au sol, ce qui rend impossible le réglage du canal sur le signal si vous voyagez trop vite.
  3. Le micrologiciel devra faire une acquisition à froid si aucune estimation de position / temps n'est disponible. Il recherchera des intervalles de fréquence doppler et des phases de code pour trouver un signal. La plage de recherche sera limitée à la plage attendue pour un utilisateur au sol.
  4. Le micrologiciel utilise généralement le filtrage Kalman pour les solutions de position. Cela implique un modèle de position / vitesse / accélération du récepteur. Bien que l'accélération ne soit pas un problème pour un satellite, le modèle échouera pour la vitesse, si le firmware n'est pas adapté pour une utilisation en orbite.

Tous ces problèmes peuvent être résolus si vous utilisez un frontend et un corrélateur librement programmables avec un firmware personnalisé. Vous pouvez, par exemple, regarder Piksy .


Pour le point 1. (bande passante frontale), la bande passante d'origine du signal est beaucoup plus large que le décalage Doppler - considérez le pire des cas, à environ 10 km / s de vitesses relatives vs 3E + 05 km / s, la vitesse de la lumière sera d'environ 50 kHz. Mais 2, 3, 4 sonnent tous comme des rupteurs potentiels pour des puces et des micrologiciels optimisés pour le consommateur.
uhoh

2
@uhoh: Je suis d'accord avec votre argument sur la bande passante, mais le point 1 ne concerne pas la bande passante. J'aurais dû mieux expliquer. Si votre taux d'échantillonnage est de 16,368,000 / s et que le signal en IF est centré à 4,092,000 Hz, et que vous avez un a / d avec une résolution de 4bits, alors vous avez un problème de battement. Chaque erreur de troncature des échantillons ira dans la même direction. Il y a tout un tas de ces mauvais points (zéro IF est un autre vraiment mauvais mais toute harmonique est mauvaise). Vous voudrez garder la distance (dépend de la période d'intégration) à ces points pour tout doppler attendu.
Andreas

Très bien, merci beaucoup pour cette réponse! Cela me donne beaucoup d'informations sur ce qui se passe. Je ne comprends toujours pas l'erreur de battement / troncature, mais je peux aller lire et peut-être poser une question par la suite. J'ai une question ACD différente qui est liée aux ADC haute fréquence trois bits (PiSky a un ADC 3 bits).
uhoh

1
Cela a à voir avec le S / N des échantillons individuels, ce qui est vraiment mauvais. Investir dans plus de précision à l'ADC n'améliorera pas beaucoup les performances globales du système. C'est un compromis compliqué, je vais essayer de donner une réponse utile à votre question ALMA.
Andreas

4

Certaines personnes implémentent COCOM en tant que ou , d'autres en tant que et . Quoi qu'il en soit, pour les clients qualifiés sous EAR ou ITAR, les fournisseurs se feront un plaisir de vous vendre une option de firmware pour $$$ qui désactive cette fonctionnalité. Le matériel est identique.

En dehors de cette limitation stricte, cela devient un problème de communication RF, tout comme la conception de votre matériel pour tolérer les effets des radiations. Votre Eb / N0 sera probablement un peu meilleur car vous êtes (littéralement) plus proche des SV et évitez la perte de chemin atmosphérique, mais vos circuits de réception devront également tolérer une quantité considérable de Doppler.

Soit dit en passant, ce n'est pas seulement la position qui intéresse CubeSats - le temps GPS est un produit de données précieux qui aide un satellite à savoir où il se trouve, étant donné un TLE. Même si le récepteur refuse de vous donner un poste à cause de COCOM, s'il donne le temps, cela peut valoir le coup.


Que signifient "Eb / N0" et "SVs"? Savez-vous avec certitude si l' heure réelle est signalée lorsque les coordonnées spatiales sont bloquées, ou voulez-vous simplement dire le signal 1pps? Veuillez noter, j'ai spécifié: "Ignorer la mise en œuvre des limites CoCom, et tous les autres problèmes de fonctionnement dans l'espace en plus de la vitesse .."
uhoh

Il y a deux ans, les satellites ont été reclassés comme "non-munitions", de sorte que l'ITAR ne s'appliquait plus - mais maintenant l' EAR s'applique comme vous le mentionnez. Il y a encore le MTCR et l' Arrangement de Wassenaar aussi et peut-être même plus!
uhoh

3
@uhoh Je suppose que les termes sont Eb / N0 => rapport signal / bruit et SV => véhicules spatiaux (les satellites GPS réels)
user2943160

@ user2943160 Merci, c'est logique. J'essaie toujours d'apprendre de nouvelles choses - si Eb est un terme spécifique, j'aimerais l'apprendre.
uhoh

Je viens de faire beaucoup de trucs de communication ces derniers temps, Eb / No est juste le SNR "normalisé", ou SNR par bit. Vraiment, il aurait probablement été plus précis d'utiliser simplement SNR ou RSSI dans cette réponse. Pour l'anecdote, j'ai entendu dire que certains chipsets (SiRF je pense) rapporteront toujours du temps mais vous gèleront hors de position, mais je ne l'ai pas personnellement confirmé.
Krunal Desai

2

Si cet article sur l'architecture GPS par exemple est représentatif, les puces sont constituées d'un frontal RF, de corrélateurs matériels dans le domaine numérique, et tout le décodage réel du signal est effectué par logiciel.

Dans ce cas, le seul problème probable est le doppler. Le logiciel peut ignorer les valeurs "exceptionnelles", mais vous devrez de toute façon remplacer ou modifier le micrologiciel si vous souhaitez contourner les limites CoCom.

Une question plus intéressante est de savoir si vous pouvez emprunter un simulateur GPS qui peut être programmé pour simuler le boîtier à haute vitesse. J'aurais pensé que ce serait possible - après tout, comment un fabricant testerait-il que son appareil applique les limites CoCom?


3
Notez que même à 0 km / h, vous devez faire face au Doppler, car les satellites se déplacent déjà à 8000 m / s.
Dmitry Grigoryev

J'aime ta logique! C'est vraiment un décalage de type (jusqu'à) +/- 60 kHz appliqué différemment à chaque signal satellite, il est fort probable que la plupart des simulateurs puissent le faire. Pour mémoire, je ne fais pas vraiment ça - je demande juste ça!
uhoh

2
Non @DmitryGrigoryev vous vous trompez sur le 8000. Ils se déplacent beaucoup plus lentement car ils sont sur des orbites beaucoup plus hautes. Mais vous avez raison, il y a beaucoup de Doppler en plus du mouvement de l'unité GPS. C'est un bon point!
uhoh

@uhoh Mon erreur. Mon commentaire devrait plutôt indiquer 14 000 km / h.
Dmitry Grigoryev

5
C'est beaucoup moins pertinent au sol - la vitesse tangentielle à l'observateur ne provoque pas de doppler. Il ne provoque cependant un petit effet relativiste: physics.stackexchange.com/questions/1061/...
pjc50

2

Cela dépend vraiment de la mise en œuvre. Par exemple, un récepteur sur lequel j'ai travaillé a un registre de fréquence NCO à porteuse à virgule fixe dans chaque canal de corrélation, avec une largeur de 17 bits. La valeur maximale pouvant être stockée dans ce registre correspond à environ 6 km / s et doit également inclure une contribution de l'erreur de fréquence d'horloge du récepteur. Il ne serait donc pas en mesure de suivre les satellites dont le taux de portée dépasse cette limite, ce qui serait beaucoup si le récepteur se déplace à des vitesses orbitales.


1

Cubesats peut être utilisé avec des unités GPS commerciales standard qui sont inférieures à 1000 $. Le fabricant supprime les limites, donc on espère pouvoir tester avec les supprimés. Ils ont des émulateurs GPS ou y ont accès.

Les limites de cocom doivent être supprimées par le fabricant, et le fabricant ne le fera que si vous pouvez obtenir une exception auprès de votre gouvernement. Je ne suis pas sûr du processus, mais je sais que c'est possible au moins aux États-Unis. En dehors des États-Unis, cela peut être presque impossible.

Je ne connais pas la précision de l'unité GPS, mais il reste des effets ionosphériques qui doivent être pris en compte, si vous volez en LEO. Vous aurez également besoin d'un système ADCS décent pour estimer la position de vos engins spatiaux


Les effets ionosphériques n'induiraient-ils pas encore des erreurs sur l'échelle des mètres ou des dizaines de mètres dans le pire des cas? À moins que son cubesat ne fasse des choses qui nécessitent un chronométrage en millisecondes ou un vol en formation basé sur GPS, cela ne finirait pas par avoir de l'importance pour la plupart des cubesats. Il est bon de se souvenir cependant, merci!
uhoh
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.