Contrôle setup astrophotographie nomade

[patdut]

Le 12/05/2019 à 18:03, Peebee a dit :

Cool cela marche sur une tinker board.  Je vais tester sur un RPI ce soir

Je ne suis pas sur que cela soit raisonnable sur un RPI même un 3B+ trop peu de mémoire .

 

Maintenant j'ai un doute sur son utilité, il faut démarrer Indi et Phd2 avant il nous faut donc accéder au nanoPC pour les lancer via VNC par exemple, et dommage que cela ne fonctionne pas en INDI remote (Enfin j'ai pas trouvé, mais j'ai pas chercher très longtemps)

 

En revanche pour une utilisation astrophoto Why not tout les outils y sont
Ceci dit c'est a suivre

 

 

 

Mobindi est un client du serveur INDI donc pour démarrer le serveur INDI au travers de la connexion il faut utiliser indi-webmanager. Pour lancer PHD2, on peut demander à l'auteur de mobindi de mettre un bouton pour le démarrer. Il est ouvert à toutes suggestions que l'on peut lui transmettre au travers de son github.

Moi je pense que c'est utile. C'est la quintessence du nomadisme. Un bon PC monocarte et un client léger sur tablette ou téléphone pour contrôler. Après si il y a des manques il faut aider le développeur à les combler en lui remontant les problèmes et les suggestions.

Modifié 28 mai 2019 par patdut

[dragonlost]

Il y a 15 heures, patdut a dit :

Mobindi est un client du serveur INDI donc pour démarrer le serveur INDI au travers de la connexion il faut utiliser indi-webmanager. Pour lancer PHD2, on peut demander à l'auteur de mobindi de mettre un bouton pour le démarrer. Il est ouvert à toutes suggestions que l'on peut lui transmettre au travers de son github.

Moi je pense que c'est utile. C'est la quintessence du nomadisme. Un bon PC monocarte et un client léger sur tablette ou téléphone pour contrôler. Après si il y a des manques il faut aider le développeur à les combler en lui remontant les problèmes et les suggestions.

En plus c'est la seul solution pour une application de controle. Malheureusement, jasem (le principale développeur de kstars) est un train de développer une application similaires mais elle ne sera fonctionnel que sur stellarmate

[dragonlost]

Bonne nouvelle ! Le développement de planetary imager a repris !

On vas peut être pouvoir enfin l'utiliser avec les camera qhy en direct ou/et avec les carte aarch64 !

 

Je rapelle l'intérêt de planetary imager  par rapport a oacapture : il est compatible avec. Les camera indi !

[src386]

Bonjour, la question va peut-être paraître bête, mais après avoir lu les quinze premières pages et les quelques dernières, je n'arrive pas à comprendre exactement à quoi ressemble ce projet et comment il fonctionne. Et surtout pourquoi ça plutôt qu'un PC portable ? En bref est-ce qu'il y a une doc centralisée quelque part ? Le github ne mentionne que la procédure d'install, et le site http://nafabox.linux-astro.fr/#StellarMate ne semble contenir aucune information utile et certaines sections bouclent sur elles-mêmes.

[Alarcon yves]

Bonjour,

Le 30/05/2019 à 23:17, dragonlost a dit :

Bonne nouvelle ! Le développement de planetary imager a repris !

On vas peut être pouvoir enfin l'utiliser avec les camera qhy en direct ou/et avec les carte aarch64 !

Je rapelle l'intérêt de planetary imager  par rapport a oacapture : il est compatible avec. Les camera indi ! 

"oacapture" reconnait parfaitement les qhy, du moins la mienne (qhy5IIL).

Dans tous les cas sa fonctionne sur une tinker-board, le seul problème c'est que "oacapture" fait chauffer le cpu, mais si on limite les GHz par les commandes suivantes (sur une tinker-board)

-> sudo cpufreq-set -c 0 -d 0.408GHz -u 1.2GHz

-> sudo cpufreq-set -c 1 -d 0.408GHz -u 1.2GHz

-> sudo cpufreq-set -c 2 -d 0.408GHz -u 1.2GHz

-> sudo cpufreq-set -c 3 -d 0.408GHz -u 1.2GHz

Après ça roule tous seul, si on reste raisonnable en nombre d'image / seconde.

Oui, c'est une bonne nouvelle que le développement de "planétary imager" reprenne, car plus on de soft pour piloter les cam, mieux c'est.

 

il y a 32 minutes, src386 a dit :

Bonjour, la question va peut-être paraître bête, .................... Et surtout pourquoi ça plutôt qu'un PC portable ?

Une partie de la réponse, c'est comme le boitier reste fixé sur la lunette/télescope,  on peut laisser également les cam sur la lunette, donc on ne défait aucun branchements à part l'alim et le câble réseau,   c'est plus rapide et moins risqué de faire comme ça, que de devoir tout débranché / démonter,  et comme c'est pilotable à distance, le PC principal il reste au chaud (son utilisateur aussi).

Yves.

Modifié 3 juin 2019 par Alarcon yves

[patdut]

il y a 4 minutes, src386 a dit :

Bonjour, la question va peut-être paraître bête, mais après avoir lu les quinze premières pages et les quelques dernières, je n'arrive pas à comprendre exactement à quoi ressemble ce projet et comment il fonctionne. Et surtout pourquoi ça plutôt qu'un PC portable ? En bref est-ce qu'il y a une doc centralisée quelque part ? Le github ne mentionne que la procédure d'install, et le site http://nafabox.linux-astro.fr/#StellarMate ne semble contenir aucune information utile et certaines sections bouclent sur elles-mêmes.

Bonjour, libre à toi d'utiliser un PC sur le terrain avec une énorme batterie pour l'alimenter.

Bon, ce projet est né de la convergence de plusieurs idées:

1/ Un PC ça consomme et ça consomme énormément sur le terrain. Un SBC (single board computers) à base d'ARM ça consomme environs 5 fois moins que le moins puissant des Intels en régime d'utilisation "standard".

2/ Le monde du libre sous Linux est riche de pépites logicielles qui font superbement le boulot.

3/ Proposer à l'astronome amateur un moyen de contrôler tout son matériel pour un coût le plus serré possible.

Le nom n'est pas choisi au hasard:  NAFABox veut dire Nomad Astronomy For All.

Quelques remarques:

Les logiciels qu'on intègre sur la NAFABox sont pour la presque totalité licenciés GPL. Ils sont puissants et encore en pleine évolution. Parce que la communauté des développeurs est riche et nombreuse, le cœur de la NAFABox, le serveur INDI dispose déjà d'une base de drivers plus importante que celle d'ASCOM. La "tour de contrôle" est constituée de Kstars et Ekos. Les développeurs de ces logiciels sont très accessibles et les corrections et évolutions sont rapides. De plus Linux est un système très stable.

Bon voici un peu la philosophie: léger, pas cher, économe en énergie, flexible (fonctionnement à géométrie variable: remote partiel ou complet) tout ça sans renoncer à la puissance, et surtout axé nomade.

Ceci dit, les systèmes SBC utilisés de plus en plus puissants et les optimisations logicielles  vont permettre, au-delà du pilotage et de la prise de vue ,d'augmenter les fonctionnalités de la NAFABox  avec  le pré-traitement des images, ou encore le live astro.

Tout ça c'est dans les tuyaux et devrait être disponible dans les mois à venir.

 

 

 

 

[src386]

il y a 56 minutes, Alarcon yves a dit :

Une partie de la réponse, c'est comme le boitier reste fixé sur la lunette/télescope,  on peut laisser également les cam sur la lunette, donc on ne défait aucun branchements à part l'alim et le câble réseau,   c'est plus rapide et moins risqué de faire comme ça, que de devoir tout débranché / démonter,  et comme c'est pilotable à distance, le PC principal il reste au chaud (son utilisateur aussi).

Yves.

Ah d'accord le dernier point est clairement un avantage, merci.

 

il y a 55 minutes, patdut a dit :

Bonjour, libre à toi d'utiliser un PC sur le terrain avec une énorme batterie pour l'alimenter.

Bon, ce projet est né de la convergence de plusieurs idées:

1/ Un PC ça consomme et ça consomme énormément sur le terrain. Un SBC (single board computers) à base d'ARM ça consomme environs 5 fois moins que le moins puissant des Intels en régime d'utilisation "standard".

2/ Le monde du libre sous Linux est riche de pépites logicielles qui font superbement le boulot.

3/ Proposer à l'astronome amateur un moyen de contrôler tout son matériel pour un coût le plus serré possible.

Le nom n'est pas choisi au hasard:  NAFABox veut dire Nomad Astronomy For All.

Quelques remarques:

Les logiciels qu'on intègre sur la NAFABox sont pour la presque totalité licenciés GPL. Ils sont puissants et encore en pleine évolution. Parce que la communauté des développeurs est riche et nombreuse, le cœur de la NAFABox, le serveur INDI dispose déjà d'une base de drivers plus importante que celle d'ASCOM. La "tour de contrôle" est constituée de Kstars et Ekos. Les développeurs de ces logiciels sont très accessibles et les corrections et évolutions sont rapides. De plus Linux est un système très stable.

Bon voici un peu la philosophie: léger, pas cher, économe en énergie, flexible (fonctionnement à géométrie variable: remote partiel ou complet) tout ça sans renoncer à la puissance, et surtout axé nomade.

Ceci dit, les systèmes SBC utilisés de plus en plus puissants et les optimisations logicielles  vont permettre, au-delà du pilotage et de la prise de vue ,d'augmenter les fonctionnalités de la NAFABox  avec  le pré-traitement des images, ou encore le live astro.

Tout ça c'est dans les tuyaux et devrait être disponible dans les mois à venir.

Merci de la réponse, je suis déjà sous Linux, et déjà convaincu par les solutions libres. Mon laptop est sous Debian + Mate, je fais mes captures avec Planetary Imager dans la cambrousse et je peux tenir 5h sur batterie sans trop de difficultés. C'est pour ça que je pose la question.

 

Ma monture n'est pas pilotable donc je ne pense pas pouvoir profiter de tout ceci pour le moment.

[dragonlost]

Hello. Par contre les scripts d'installation de la nafabox ne sont pas adaptés a debian mais si tu passe sur Ubuntu tu pourra installer ton ordinateur portable avec.

[jjc]

Bonjour scr386,

Comme toi, je préfère debian, mais pour indi, c'est beaucoup plus pratique d'utiliser ubuntu.

J'ai donc mixer les 2:

- indi avec ubuntu sur la tinker (ou rpi3b+)

- pc déporté sous debian-sid, avec kstars/ekos issu des dépots de la debian que j'utilise.

 

Ca marche très bien.

 

J'avais essayé de mettre armbian sur la tinker (ou rapsbian sous rpi3b+) avec indi-compilé (j'avais pas trouvé de paquets indi récents pour debian), mais c'est un peu plus galère. Et les mises à jour sont plus longues à effectuer.

[dragonlost]

Il y a 2 heures, jjc a dit :

Bonjour scr386,

Comme toi, je préfère debian, mais pour indi, c'est beaucoup plus pratique d'utiliser ubuntu.

J'ai donc mixer les 2:

- indi avec ubuntu sur la tinker (ou rpi3b+)

- pc déporté sous debian-sid, avec kstars/ekos issu des dépots de la debian que j'utilise.

 

Ca marche très bien.

 

J'avais essayé de mettre armbian sur la tinker (ou rapsbian sous rpi3b+) avec indi-compilé (j'avais pas trouvé de paquets indi récents pour debian), mais c'est un peu plus galère. Et les mises à jour sont plus longues à effectuer.

 

Après si @jjc et @src386 vous êtes vraiment motivé vous pouvais essayer de produire une version debian de la Nafabox. Si ça passe, on peut imaginer créer une branche pour vous sur le projet.

[jjc]

Salut,

C'est vrai que j'aimerai bien être plus productif sur le sujet, mais les 3 heures de transport par jour, ça m'achève .... Bon on se trouve toujours de bonnes raisons pour ne rien faire. J'essaie d'aider comme je peux de temps en temps, ça me donne bonne conscience...

Dans 3 ans, ça devrait aller mieux. Farniente.

Par contre, tous les paquets indi sont pour ubuntu. Il me semble que pour debian, armbian ou raspbian, je n'avais pas réussi à installer les paquets de Jasem/ubuntu.

Sur la debian-sid, il y a kstars et indilib, mais il n'y a pas les paquets 3rd. Je les avais donc compilés.

Mais un jour, je n'ai pas réussi.

Et puis une mise à jour sous ubuntu, c'est apt-get update puis upgrade. Quand faut recompiler....

Je suis donc repassé sous ubuntu pour le boitier indi/déporté (tinkerboard ou rpi3b+). Ce sont des NAFABox (Installation Ubuntu puis scripts que vous avez fait).

Mon pc kstars/ekos lui est sous debian/sid.

[dragonlost]

il y a 2 minutes, jjc a dit :

Salut,

C'est vrai que j'aimerai bien être plus productif sur le sujet, mais les 3 heures de transport par jour, ça m'achève .... Bon on se trouve toujours de bonnes raisons pour ne rien faire. J'essaie d'aider comme je peux de temps en temps, ça me donne bonne conscience...

Dans 3 ans, ça devrait aller mieux. Farniente.

Par contre, tous les paquets indi sont pour ubuntu. Il me semble que pour debian, armbian ou raspbian, je n'avais pas réussi à installer les paquets de Jasem/ubuntu.

Sur la debian-sid, il y a kstars et indilib, mais il n'y a pas les paquets 3rd. Je les avais donc compilés.

Mais un jour, je n'ai pas réussi.

Et puis une mise à jour sous ubuntu, c'est apt-get update puis upgrade. Quand faut recompiler....

Je suis donc repassé sous ubuntu pour le boitier indi/déporté (tinkerboard ou rpi3b+). Ce sont des NAFABox (Installation Ubuntu puis scripts que vous avez fait).

Mon pc kstars/ekos lui est sous debian/sid.

 

Pas de problème ! c'était pas un reproche mais plutôt une invitation. Je sais que c'est passible d'installer kstars + indi +3rd sur raspbian car je l'avais fait avant la création de la Nafabox. Il faut ajouter le PPA de Jasem et utiliser les package SID. Après y  a pas mal d'autre modification c'est pour ça que ça ne pourra pas être intégrer  au script Nafabox mais plutôt à une branche alternative.

 

 

[src386]

il y a 47 minutes, dragonlost a dit :

 

Après si @jjc et @src386 vous êtes vraiment motivé vous pouvais essayer de produire une version debian de la Nafabox. Si ça passe, on peut imaginer créer une branche pour vous sur le projet.

 

Je ne pense pas que ce soit une bonne idée de maintenir 2 versions de la nafabox, en plus des variantes pour les board arm.

 

J'ai pas de monture motorisée, si un jour c'est le cas j'utiliserai l'image nafabox standard, ou alors j'installerai les composants sur mon laptop Debian. Mais il ne faut pas se lancer dans une fragmentation du projet.

[jjc]

Je ne l'ai pas pris comme un reproche. C'est moi qui me le reproche.  En plus, j'adore faire ça. Et je suis admiratif du travail que vous faites. Je viens de vérifier, et les paquets indi pour le rpi sont toujours très anciens (1.7.4). A mon avis, ce n'est plus maintenu. Plus personne ne doit les utiliser.

Je me rappelle que ce qui me gênait sur le ppa/ubuntu de Jasem, ce sont les paquets atik, et les dépendances avec les librairies. J'avais bidouillé en créant des liens, mais bon... pas terrible.

Maintenant que atik est mieux intégré, il y a peut-être moins de problème. Je vais au moins essayer.

il y a 21 minutes, dragonlost a dit :

Je sais que c'est passible d'installer kstars + indi +3rd sur raspbian car je l'avais fait avant la création de la Nafabox. Il faut ajouter le PPA de Jasem et utiliser les package SID

 

Qu'entends-tu par là ? Dans Armbian/Raspbian il est aussi possible d'utiliser des versions sid comme sous debian ? C'est ça ?

[jjc]

il y a 16 minutes, jjc a dit :

Qu'entends-tu par là ? Dans Armbian/Raspbian il est aussi possible d'utiliser des versions sid comme sous debian ? C'est ça ?

 

Ah oui, je viens de voir dans raspbian qu'il y a des notions de versions stable/testing/sid comme dans debian et qu'on peut mixer.

A priori, tout le monde n'est pas d'accord pour créer des versions //. Je vais au moins essayer pour moi.

De toute façon, il ne va pas faire beau 😀

[dragonlost]

il y a 2 minutes, jjc a dit :

 

Ah oui, je viens de voir dans raspbian qu'il y a des notions de versions stable/testing/sid comme dans debian et qu'on peut mixer.

A priori, tout le monde n'est pas d'accord pour créer des versions //. Je vais au moins essayer pour moi.

De toute façon, il ne va pas faire beau 😀

 

C'est ça exactement.

 C'est l'avantage des projet opensource : vous pouvez en faire ce que vous voulez ! C'est grâce à ca que j'ai pu reprendre quelque projet et c'est comme ça que j'ai pu rentrer dans le projet nafabox.

 

D’ailleurs quelqu'un connaît il la procédure pour compiler la version compatible avec INDI de Audela  ? Moi but c'est de réussir à le compiler pour armhf et aarch64.

[yeantbron]

salut, alors je sais pas ce qui cloche, bin deja un truc si lol, surement la compatibilité linux/asi, j'ai pourtant opté pour celle en usb3, mais beaucoup de deconnexion de celle ci.

impossible d'aligner la polaire, ça calcule sans fin a la 1ere photo,

mais la ou le bat blesse, c'est qu'avec le guidage activé, j'ai plus de filé d'etoile que sans (mais bien plus), comme si la monture tourné en accéléré ou même a l'envers...

[patdut]

Il y a 7 heures, yeantbron a dit :

salut, alors je sais pas ce qui cloche, bin deja un truc si lol, surement la compatibilité linux/asi, j'ai pourtant opté pour celle en usb3, mais beaucoup de deconnexion de celle ci.

impossible d'aligner la polaire, ça calcule sans fin a la 1ere photo,

mais la ou le bat blesse, c'est qu'avec le guidage activé, j'ai plus de filé d'etoile que sans (mais bien plus), comme si la monture tourné en accéléré ou même a l'envers...

Salut,

Dis moi quelle est la caméra que tu utilises pour la mise en station Ekos ? As tu deux Zwo sur ton setup ?

 

A faire :

 

Vérifie que le champ utile est suffisant pour réaliser la mise en station. Utilises pour cela l'outil de calcul/représentation de champ de Kstars.

Vérifie que tu disposes bien de tous les index nécessaires pour la résolution astrométrique.

Réglr le temps de pose qui doit être suffisant pour que le solveur ait suffisamment d'informations pour l'opération.

Assures toi être en binning 2.

Fais une résolution astrométrique sans action. Ça permet de s'assurer que tout est OK.

Normalement une fois cela fait tu devrais réussir ta mise en station.

 

Pour le guidage, plusieurs trucs qu'il faut vérifier et régler:

- Dans les options  ne pas hésiter à augmenter la durée d'impulsion pour la calibration (1000 par défaut moi j'ai mis 1500 à cause d'échecs). Ça accélère le processus et évite l'échec.

- Vérifier la vitesse de rattrapage, en général 0,5x, elle doit être identique  sur la monture (parfois modifiable uniquement depuis la raquette) et dans l'onglet télescope du device manager. Cette vitesse permet le calcul du paramètre P dit gain proportionnel.

- Une fois qu'on dispose de la valeur du gain proportionnel il faut aller dans l'onglet paramètres situé au dessus de la cible en bas à droite  de l'onglet autoguidage. Là on reporte sur la première ligne des paramètres la valeur P. Ensuite on va ajuster la valeur de l'impulsion sur la dernière ligne des paramètres de la manière suivante: supposons que je cible une valeur d'erreur RMS de 0,5" alors je multiplie la valeur de P par 0,5" et j'obtiens la valeur de la durée d'impulsion à reporter sur cette dernière ligne. Ensuite j'itère autour de cette valeur pour me rapprocher au mieux de la valeur de consigne c.à.d 0,5" RMS.

- dernière opération, régler la durée de prise de vue sur 2 ou 3 secondes.

 

Normalement une fois tout cela fait ça devrait aller mieux.

 

 

Modifié 5 juin 2019 par patdut

[TonyBANKS75]

Salut les auto-guideurs,

il y a 24 minutes, patdut a dit :

Assures toi être en binning 2. [...]

Tiens j'ai entendu exactement les mêmes conseils de @gehelem qui tirait ces infos d'un certain @patdut 😋.

Ça marche, d'une manière générale, assez bien. Mais il faut passer un peu de temps à peaufiner les réglages pour atteindre le nirvana. Pour ma part, j'en suis pas encore là.... La monture se barre en sucette au bout de quelques minutes. Mais c'est pas forcément la faute d'une Nafabox, ou d'une caméra. Il y a tellement de paramètres à prendre en compte : équilibre de la monture, rigidité des supports, flexion de monture, darks ou pas sur l'image, etc... D'ailleurs, j'incriminerais plutôt la monture et ses erreurs périodiques et d'autres plus"aléatoires".

Il faut de la méthode, de la Méthode 😁.

@yeantbron, pour estimer une première fois le champs pour l'astrometrie, tu peux regarder http://www.12dstring.me.uk/fovcalc.php

Ça marche bien et tu verras que cela va diminuer le temps mis pour la résolution astrometrique

Tony

Modifié 5 juin 2019 par TonyBANKS75

[yeantbron]

ouch bien compliqué tout ca lol

je vais essayer de voir ce que ça donne, par contre sur la star adventurer la vitesse de rattrapage je ne la connais pas.

 

Merci pour les precisions

[keymlinux]

Bonjour,

 

Le 12/04/2018 à 14:37, dragonlost a dit :

Moi je rêve d'un raspberry pi 4 avec wifi ac, 2 go de ram, un système enfin 64bits, Ethernet gigabit et soyons fou un port usb3 et 2 port USB 2.0.

-> sur la version 3B+ on a le wifi ac (300Mbits), le port gigabit (brider par l'usb 2.0). Encore un effort et on y est !

 

@dragonlost tu l'avais rêvé, ils l'on fait, le Raspberry PI 4 est dispo, avec au choix 1, 2 ou 4GB de RAM, ethernet gigabit, 2 ports usb 2.0 et 2 ports usb 3.0,  quad-core 1.5Ghz, Wifi bi bande 2.4 et 5 Ghz. Moins utile pour une utilisation nafabox, il gère aussi 2 sorties vidéo 4K via ports micro-hdmi.

https://www.raspberrypi.org/products/raspberry-pi-4-model-b/

 

Il n'y a plus qu'a tester...

 

@+

[dragonlost]

Le 04/06/2019 à 14:32, jjc a dit :

Je ne l'ai pas pris comme un reproche. C'est moi qui me le reproche.  En plus, j'adore faire ça. Et je suis admiratif du travail que vous faites. Je viens de vérifier, et les paquets indi pour le rpi sont toujours très anciens (1.7.4). A mon avis, ce n'est plus maintenu. Plus personne ne doit les utiliser.

Je me rappelle que ce qui me gênait sur le ppa/ubuntu de Jasem, ce sont les paquets atik, et les dépendances avec les librairies. J'avais bidouillé en créant des liens, mais bon... pas terrible.

Maintenant que atik est mieux intégré, il y a peut-être moins de problème. Je vais au moins essayer.

 

Qu'entends-tu par là ? Dans Armbian/Raspbian il est aussi possible d'utiliser des versions sid comme sous debian ? C'est ça ?

Ouaip j'ai vue ça hier ! il reste plus qu'à attendre qu'un ubuntu tourne dessus !

Si elle tien ses promesse elle pourrai devenir le future de la nafabox.

 

En attendant la version 3.3 arrive a grand pas ( en cours de teste)

[gehelem]

Rpi4 = ordered.

[vinvin]

Si seulement les caméras astro étaient à ce prix là aussi

En tout cas ça a l'air cool ! Ca a pas l'air simple niveau OS mais c'est sûrement mieux que nvidia

[jjc]

Bonjour,

Ma Asus et mon RPI3B+ se sentaient un peu seuls .....

Une petite copine RPI4-4G vont leur faire du bien.

J'attends la 4G et je commande.

[flashball]

salut a tous

bon je vais paraitre tellement debile avec ma question

comment brancher le set up complet sur la nafabox rasbperry Pi B+?

j'ai une monture maede lxd 75 go to

une cam Touptek 2000 deep sky  auto guider

un canon 550D

j'ai deja installé l'image nafabox sur mon rasbperry 

qui a un lien tuto ou schema des branchements 

 

merci d'avance

 

je suis un novice ...😂

[ganlhi]

Je vous vois parler du RPi 4, mais j'avais cru comprendre qu'on ne pouvait pas encore faire une NafaBox avec car Ubuntu Mate n'était pas encore dispo pour lui. Je me trompe ? 

[trasher]

je te dirais ca dans le we

1er test avec raspbian de base ben ça passe pas  

J'ai vu que certain ont réussi a porter le ubuntu mate du Pi3, je regarde et je teste si je trouve une explication claire

Modifié 23 août 2019 par trasher

[ganlhi]

Super ! Ça m'intéresse bien car le Pi est bien moins cher que la TinkerBoard et le 4 pourrait suffire pour tout faire tourner et se connecter en VNC pour le contrôle, histoire de se passer d'un PC portable, à moins que je me fasse des illusions ?

[gbs]

Le 22/08/2019 à 20:33, flashball a dit :

salut a tous

bon je vais paraitre tellement debile avec ma question

comment brancher le set up complet sur la nafabox rasbperry Pi B+?

j'ai une monture maede lxd 75 go to

une cam Touptek 2000 deep sky  auto guider

un canon 550D

j'ai deja installé l'image nafabox sur mon rasbperry 

qui a un lien tuto ou schema des branchements 

 

merci d'avance

 

je suis un novice ...😂

Si tu parles des connections électroniques, tu fais en fait comme si tu voulais brancher un pc. Il te faut raccorder l'APN avec son câble usb, ta cam de guidage également et ensuite la monture, donc avec le câble dédié (moi j'ai le Pierro Astro pour EQ6). 

 

Si tu peux préciser ta question...