Jump to content

Protocole GPS/SynScan


Recommended Posts

Voulant un GPS pour ma raquette SynScan (éviter de rentrer la date et la position quand je bouge), j'ai essayé de trouver le protocole utilisé.

 

Il est basé sur un protocole binaire utilisé par LocSence/Prolofic. gps_rfsolutions_DS-41COM-2.pdf

 

Au démarrage ou quand on rentre dans le menu GPS, la raquette va essayer de détecter un GPS :

 

Raquette -> GPS : %%<F1h><13h>< Parameter byte><CS><CR><LF>: Set Output Format (13h) avec comme Parameter byte 0: No output

 

GPS -> Raquette : %%<06h><Response 13h><CS><CR><LF> : Ack

 

Raquette -> GPS : %%<F1h><13h>< Parameter byte><CS><CR><LF>: Set Output Format (13h) avec comme Parameter byte 3. Binary

 

GPS -> Raquette : %%<06h><Response 13h><CS><CR><LF> : Ack

 

A ce moment la raquette va se mettre en attente du message de position GPS. C'est le message "User Position, Velocity & Time II (D1h)"

 

06f56399-e7c5-4778-aaf6-d91ac6a04216.jpg

 

L'idée est d'utiliser un Arduino Mini pour la conversion entre un GPS NMEA et le protocole binaire.

 

Dans le montage, il y a:

  • Arduino Mini
  • Convertisseur 12v -> 5v
  • Convertisseur RS232/TTL pour adapter la tension
  • Un cable RJ à brancher sur la raquette pour le 12v & le RS232

 

e5d66a9b-07f0-4076-87fd-5cf41f804151.jpg

 

Il ne reste qu'a terminer le programme qui tourne sur l'arduino. Pour l'instant il me reste un bug au niveau de l'encodage de la longitude & latitude (problème de format au niveau des float).

Link to post
Share on other sites
  • 3 years later...
  • 2 years later...

Je n'ai jamais trouvé l'encodage de la longitude & latitude 😢 Il semble y avoir une conversion mais impossible de savoir si c'est un mauvais encodage, un problème de référentiel ou fait exprès pour obliger de passer par le GPS de skywatcher, en gros on a : 2.0E-39 = 0.119°, 2.0E-37 = 3.56°, 2.0E-20 = 43°, 2.0 = 90°

Il faudrait avoir le vrai GPS pour comprendre comment est envoyé la longitude & latitude.

 

En PJ, le code Arduino

SynScanGPS.ino

Link to post
Share on other sites
  • 3 weeks later...

Après quelques tests avec des valeurs aléatoires, on trouve :

0x00000100 => 00°00'00.00N
0x00001000 => 00°00'01.2"N
0x00010000 => 00°00'19.7"N
0x00100000 => 00°05'16.4"N
0x01000000 => 01°24'22.5"N
0x10000000 => 22°30'00.0"N
0x20000000 => 45°00'00.0"N
0x30000000 => 67°30'00.0"N
0x40000000 => 90°00'00.0"N
0xc0000000 => 90°00'00.0"S
0xd0000000 => 67°30'00.0"S
0xe0000000 => 45°00'00.0"S
0xf0000000 => 22°30'00.0"S

 

Et donc 90.0 * 1e-45 affiche 90°00'00.0"N sur la raquette. Sauf que maintenant je suis limité par la précison en flottant de l'arduino :(

Link to post
Share on other sites

Bonjour,

 

En toute humilité, je peux le dire, je suis trop fort, j'ai trouvé !

 

1) Si on considère comme un entier sur 32bits et pas comme un flottant...

quand tu as 0x40000000 (90° N) on peut considérer 4 octets 0x40 0x00 0x00 0x00

quand tu as 0xc0000000 (90° S) on peut considérer 4 octets 0xc0 0x00 0x00 0x00

Seul le premier octet est différent, si on le considère en binaire on a :

0x40 --> 01000000

0xc0 --> 11000000

Donc si le premier bit est à 0 le chiffre est positif et c'est au Nord, et si le premier bit est 1 le chiffre est négatif et on est au sud.  Il devrait y avoir la même logique pour Est et Ouest...

 

2) Maintenant que l'on a la différence entre nord et sud, déterminons comment on arrive à 90¨

L'hexadecimal (base 16) c'est bien, mais on va parler en base décimale (10), c'st plus simple pour les humains que nous sommes (si vous ne savez pas pourquoi on compte en base 10 comptez vos doigts...)

0x40000000 en hexadecimal c'est 1073741824 en decimal

Si l'on considère qu'un entier 32 bits varie entre 0 et 2^32 (2 puissance 32 sot la plus grande valeur d'un entier 32bits), alors ce chiffre peut être converti en fraction en le divisant par 2^32.

Et si on considère que c'est une fraction de la circonférence d'un cercle,  fraction de révolution à 360°, on multiplie la fraction par 360 pour obtenir un angle decimal.

(1073741824 / 2^32) * 360 = (1073741824 / 4294967296) * 360 = 0.25 * 360 =  90

CQFD !

 

3) si on ne ne préoccupe pas du signe:

Pour 90°N on a 0x40000000

--> 0x40000000 donne 1073741824 en decimal et après le calcul ci dessus on a 90°

Pour 90°S on a 0xc0000000

--> 0xc0000000 donne 3221225472 en decimal et après calcul on obtient 270°

 

Pour faire simple, il faut faire le calcul, puis si l'angle est inférieur ou égal à 180 on le garde tel quel, si il est supérieur à 180 on soustrait 180 (on fait un MODULO 180) et on change le signe. Et cela fonctionnera pour NORD (de 0 à +90), SUD (-90 à 0) mais aussi pour EST (de -180 à 0) et OUEST (0 à 180). 

 

4) Si on prend par exemple 0x30000000

0x30000000 --> 805306368 en decimal

805306368  / 4294967296 * 360 = 67.5000000000  

Ce sont des degrés décimaux, et en degrés minutes secondes on a bien 67° 30'

 

5) en terme de précision requise

On divise 2 entier 32bits l'un par l'autre, le résultat sera un chiffre à virgule entre 0 et 1 donc à stocker dans un float

Si on divise 805306368  / 4294967296 avec une précision de 2 chiffres on obtient 64,80, avec 3 chiffres on obtient 67,320, avec 4 chiffres on a 67,5000

Donc avec les float sur 32bits (et pas 64 bits) de l'arduino c'est suffisant

 

6) Je te laisse faire des tests pour la longitude Est et Ouest pour vérifier s'il y a la même logique de calcul...

 

Cordialement, Stéphane

 

 

  • Merci / Quelle qualité! 2
Link to post
Share on other sites
  • 3 months later...

Effectivement ce n'est pas trop détaillé dans le GitHub.

Coté prise sur la raquette : le brochage est dans la doc SynScan (12v, GND, RS232)

Il faut un convertisseur 12v -> 5v pour alimenter l'Arduino & le GPS

Il faut un convertisseur TTL<->RS232 pour adapter les signaux entre le SynScan et l'Arduino

 

Le code est configuré pour un GPS en 4800 bauds mais la conf peut être changée en modifiant la ligne

gps.begin(4800);

Le GPS est branché sur le port série HW de l'Arduino

 

Le convertisseur RS232 vers le SynScan est branché sur les ports 8 & 9, la conf peut être aussi changée

#define RXPIN 8
#define TXPIN 9
SoftwareSerial nss(RXPIN, TXPIN);

 

Link to post
Share on other sites
  • 2 months later...

Bonjour

 

Je déterre ce poste très intéressant , je me demandais si il n'existait pas un module GPS avec directement le format de sortie en Binaire compatible avec la raquette ?

Je serais étonné que ça n'existe pas , Quelqu'un sait comment est fait le module GPS officiel Skywatcher ? . Es ce un module GPS + microcontrôleur ou juste un module qui sort directement le bon format ?

 

Merci

 

 

Link to post
Share on other sites

La première version du module GPS SynScan utilisait un chip Prolofic qui gère par défaut ce protocole spécifique. Depuis Prolofic a arrêté de fabriquer des puces GPS.

J'imagine que les nouvelles versions ont un firmware spécifique SynScan.

 

Je n'ai pas trouvé de chip GPS dont on pouvait changer le firmware facilement (sans payer des $$$ pour avoir accès aux sources du firmware) donc la solution la plus simple/moins chère est d'ajouter un arduino pour faire le transcodage.

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.