Bon, de mon côté, j'ai acheté il y a un bout de temps le Silex 4000, je l'ai intégré
dans un observatoire "test" pour évaluer la solution.
Perso, je n'ai pas été satisfait de la solution, alors que tout le monde indique qu'elle
est "idéale"...
Mes remarques :
- problème de driver et de stabilité...
- les logiciels de capture ont le choix entre (pour faire simple) 3 normes de
fonctionnement avec un USB... 2 sont "standardisées", 1 est "plus libre"...
Et, manque de pot, toutes mes solutions (liées aux hardware des CCD et autre)
utilisent tous la solution "je fais mon mode perso"...
Et là : Silex, Belkin, DLink et autres (je les ai tous) : nada !
Donc, la clé du succès est de
d'abord faire le choix du matériel de capture compatible avec les solutions de remote, et
pas l'inverse !
Ex : dans le tas de Atic, DHY, SBIG, DMK que je possède (ou ai possédé),
seule la DMK est la "passe partout" qui est utilisable...
DHY = très mauvaise qualité de software... Une solution pour forcer le
ré-achat dès qu'ils décident de ne plus supporter le driver. Sur 5 installation, 2 opérationnelles
et le reste : après quelques heures, tu méprises la solution !
Mais comme le matos n'est pas trop cher, c'est une stratégie marketing.
ATIC = tu peux en parler à certains du club (et d'un autre), qui ont testé (vainement) de
faire fonctionner une CCD que je leur ai passée dans tous les modes : Windows, Linux, RaspBerry
Résultat : nada ! la seule solution : racheter le modèle suivant, qui lui "devrait aller mieux"...
Peut-être, mais pour combien de temps ?
=> Atic, interrogé, assume parfaitement. Une CCD est "opérationnelle" 7-8 ans, mais pour le soft
de cette période : plus réellement supporté, donc : si problème, remplacez...
DMK : un miracle, mais qui s'explique à cause d'un protocole très bien décrit et ouvert...
Mais le marché principal de ces caméras est l'industrie, et ceci explique cela...
Fonctionne sous tous les OS, tous les modes, toutes les versions...
Mais hélas : les intégrations "capteur", "performances" et "rapport qualité/prix"
pour l'astronomie "datent"
désormais, comparé aux nouvelles caméras du marché...
SBIG : élitiste... (pour ne pas dire snobisme), ne fonctionne bien qu'avec "leurs" solutions ou solutions "partenaires"...
Quand on fait une remarque à leur service après-vente (j'avais acquis d'occase un modèle relativement ancien,
mais parfaitement opérationnel), on te prend (vraiment) pour un c... La seule chose qu'ils répliquent,
c'est : "
comment vous pouvez encore travailler avec cela ?". Cela se traduit dans leur stratégie marketing...
Si vous avez les moyens de nous acheter, l'argent n'a pas d'importance...
ZWO : le nouveau venu... Je n'en ai pas encore, donc : pas d'opinions à présenter.
Plusieurs acteurs m'indiquent un bon support, très ouvert, et d'ailleurs, disponibles sous
beaucoup de plateforme d'intégration : Indy, Ascom, Natif (et de facto, de OS : Windows, Linux, Raspbery)
=> pas d'opinion sur la compatibilité avec les boîtiers de type "Silex"...
Quand j'en aurai une (fin d'année), je t'en dirai plus...
Sinon, la seule solution qui était utilisable : les APN's...
Là, les boitiers de type Silex fonctionnent avec les modèles récents ! (à tester au cas par cas...
car là aussi, certains modèles : nada...)
Je te passe mes tests avec d'autres matériels (monture, capteur, spectro, analyseur,
détecteur, etc...), il y a pas mal à dire... Avec de bonnes et de mauvaises surprises...
Conclusion : - j'ai appris que si on veut faire du "remote", on se renseigne d'abord sur le matériel
supporté par le "boitier" qui doit offrir le service.... Si pas supporté : inutile ! (sauf si
on adapte le code...)
- ce n'est pas la solution la plus chère qui est la meilleure... (cf première remarque :
on considère que l'argent n'est pas un obstacle au "ré-achat" d'un matériel réellement compatible)
- je conseille les plateformes "ouvertes" (du type Raspberry), car la communauté est
plus ouverte... Si on a un problème, on peut espérer une solution.
Ce qui fonctionne toujours : avoir un pc "remote" (
près du matériel) sur lequel tu installes
les éléments (ex : avec un HUB USB,
alimenté, de
bonne qualité) et l'accéder depuis un autre
(PC, tablette, smartphone) là, avec une solution de type VNC, TeamViewer, Citrix, Google ou autres
=> cela fonctionne !
Donc, j'ai choisi cette solution pour ma solution "remote"...Avec un PC (un "serveur") dans une boîte adaptée et dédiée sur place (avec ventilo, énergie
de secours, stockage temporaire, interfaces protégées) qui est lui-même commandé
par un boitier de commutation via internet (power on/off/reboot)
=> Fiabilité : élevée... (en 3 ans, aucun problème)
=> Coût : je l'ai fait en matériel de récup, c'est le boitier qui a coûté le plus cher
=> Compatibilité : si un matériel dispose d'un "driver" sur l'OS, il fonctionnera tant
qu'il est supporté
=> Distance : Internet...
=> Sécurité : on peut installer toutes les astuces que l'on désire, ce qui est un gros avantage
Rem : je déconseille le cryptage en temps réel, sauf si on a un (très) gros CPU...
=> Durée de réaction : là, cela dépend de la solution de "remote connect" que l'on utilise,
et évidemment du réseau disponible... J'utilise actuellement le "Remote Desktop Protocol (RDP)"
(mstsc) sous Windows 10 vers un "boitier" basé Win7 et un autre basé Raspberry.
Pas de problème pour suivre (tant que l'on ne passe pas à une trop grande résolution), mais la bande
passante est toujours clé (surtout dans les phases de mise au point)... Evidemment, la puissance
du serveur joue dans l'équation...
C'est un choix, à mon sens :
- soit un PC puissant et plusieurs périphériques (donc : une session, mais très "chargée")
- soit un RaspPI par périphérique (donc : une connection + session "légère" par périphérique)
L'avantage, tu peux combiner les deux...
Ex : l'acquisition d'un SQM est aussi opérationnelle sur PI que sur PC, mais il est inutile
de l'avoir en temps réel... Un simple "file transfert" périodique suffit depuis un PI (qui consomme moins).
Donc, autant laisser le PC s'occuper du guidage et du contrôle CCD...
C'est pour cela que je m'occupe de ma connection internet (nouvel obs) en priorité...
Si on n'a pas 10 Mbits garanti, cela fonctionne, certes, mais parfois trop "peu réactif"...
Voilà... Tu as une base pour te lancer... Il y a certainement d'autres solutions, mais il
faut du temps pour les mettre en place. Et ce truc là, c'est ce que j'ai de moins....