Transfert d'images Atik314L+ avec Silex SX-3000GB...

[Jean D 0]

Bonsoir à tous,

J'ai besoin de votre aide ...en effet, j'ai réalisé des essais de prise en charge de mon matériel avec un hub USB-Ethernet Silex SX-3000 GB.

Au niveau de la config., le matériel USB est connecté au Silex, le Silex est connecté à un switch Giga, et ce dernier est connecté au PC équipé d'une carte réseau Giga (sous Win7 64).

Les résultats :
===============
Pour le pilotage de la monture Taka EM200 > OK
La roue à filtres Atik > OK
La caméra Atik 314L+...c'est là que ça se complique ... Elle est reconnue, la gestion est OK, mais c'est au niveau du transfert des images que ça coince. En USB2, ce transfert prend à peine 2 sec, mais en Ethernet, il passe de 10 à 15 secondes...alors que je suis en Giga sur toute la ligne...

Bon, ce n'est pas ces 10 à 15 secondes qui me gênent...en fait j'ai réalisé 2 "offset maître" dans les mêmes conditions dans un premier temps en USB2 et dans un deuxième temps en Ethernet Giga...et...le résultat est différent ?!

Voici ces offset réalisés avec PRiSM 7 à partir de 15 images (seuils en automatique pour les deux images) :

En USB2...

En Ethernet Giga...

Pourquoi le transfert est-il plus long en Giga qu'en USB2 ???
La différence sur les images est-elle directement liée à ce temps de transfert ?
J'ai utilisé des câbles réseau Cat5e UTP, des câbles blindés changeraient-ils quelque-chose ?
Ce phénomène pourrait-il avoir une influence sur les prises de vue ?

Soit...si vous avez des infos et des explications à ce sujet, ce serait super

Merci d'avance à tous et bon week-end !!!

Jean

[Ce message a été modifié par Jean D (Édité le 12-11-2010).]

[frédogoto 2 006]

question complexe...
difficile de répondre..
mon premier réflexe est le hub giga lui meme
j'en ai acheté un , on va dire premiere prix : résultats les Transfers ethernet bien que reconnu en Giga sont pas top du tout
si je compare au bureau ou je suis en giga j'ai des taux de Transfer égaux a la vitesse des DD (soit 25mo s)
a la maison c'est plutôt 8-9 mo quand tout va bien....

Il faut d’ailleurs savoir que un HUB n'est pas un SWITCH : le hub est incapable de conserver la BP, il divise les flux par le nombre de port OQP.
donc la ou s'est pas drôle, c'est qui "on" veu que ça aille vite en gb il faut y mettre le prix.

pour ton soucis de Transfer et offset différent...
je crois qu'il faut en aucun cas faire de seuils auto
pour avoir une base de comparaison fiable il faut que tu mettes strictement les meme valeur pour chaque image.
c'est important de procéder ainsi, car j'ai quand même vaguement l'impressions que l'offset "giga" est meilleur que l'offset USB
a Vérifier bien sur...
d'une façon générale, plus une image est transféré lentement mieux ça vaut...

[Jean D 0]

Bonsoir Frédéric,

Merci beaucoup pour ces infos...

Pour les offset, je renouvellerai l'expérience dans le courant de la semaine avec cette fois des seuils égaux pour les deux essais...on verra ce que ça donne...

J'espère bénéficier d'une soirée correcte cette semaine afin de tester la configuration Ethernet pour une séance prise de vue complète...je vous ferai part des résultats

Merci encore et bonne soirée !!!

Jean

[CielProfond23 0]

Bonsoir.

Ton problème n'a rien à voir avec la vitesse sur Ethernet, sur USB ou un problème de dégradation ou de "modification" de signal dans ta chaine.

C'est simplement que ton SILEX n'est peut être pas du tout conçu pour connecter des caméras, qui utilisent USB d'une façon spéciale.

Il existe plusieurs façons de dialoguer entre un périphérique et un maitre (PC...) sur un bus USB.

L'une est le mode dit "isochrone" qui signifie que le périphérique envoie les trames USB à intervalle temporel régulier sans s'assurer de la bonne réception ni de la demande du maitre avant d'envoyer la suivante

Au lieu d'un polling du bus à l'initiative du maitre, le périphérique bascule dans un mode spécial et se met à émettre une rafale de trames qui contiennent ses données, ici des parties d'images.

Les informations de services sont réduites au minimum, il n'y a pas d'acquittement par trame, c'est un mode dédié aux gros transferts pour lesquels on peut perdre des trames (en vidéo par exemple) sans que tout soit compromis.

La comparaison entre TCP (connecté après transaction) et UDP (non connecté ouvert en écoute) est valable.

La plupart des caméras utilisent ce mode de transfert USB dit "isochrone" pour leurs images parce qu'il permet un fort débit sans grosse consommation de ressource processeur et de bande passante USB: le périphérique "balance" ses trames sur le bus USB sans se soucier qu'elles soient bien reçus à l'autre bout parce que normalement elles le sont toujours, dans une fenêtre de temps.

Pourquoi ça marche en direct et pas en USB/Ethernet? Parce que sur un bus USB de bout en bout, la synchronisation est parfaite, et tout ce qui part à un rythme est reçu au même rythme à l'autre bout avec une grande précision.

Il est aussi possible que le SILEX qui reçoit le flux isochrone ne soit pas capable de bien séparer les trames sans acquittement et se contente de faire ce qu'il peut en remplissant un tampon au bout d'une fenêtre temporelle, ou en décidant d'un timer pour dire qu'il a reçu son quota...

Ca peut expliquer que tu mette 10 fois plus de temps: en fait la conversion USB/Ethernet est peut-être en timeout permanent par absence d'acquittement de trame USB, ou bien bascule en dégradé en USB 1.0, c'est à dire en 12 ou... 1,5 Mb parce qu'il ne sait pas gérer autrement l'isochrone.

A mon avis c'est la cause de ces flats étrangement uniformes, qui semblent reproduire de ligne en ligne la même chose avec une précision artificielle et une dérive lente des valeurs qui n'ont rien à voir avec un bruit aléatoire.

Le problème, pour ce que j'en sais, c'est que ce mode isochrone n'est pas pris en charge par les convertisseurs USB/Ethernet bureautique qui se contentent souvent des modes normaux suffisant pour presque tout.

Ca n'est pas du tout une question de défaillance, de perte d'insertion ou d'incompatibilités, mais de firmware.

C'est probablement parce que ton SILEX n'est pas prévu pour gérer le transfert isochrone utilisé par une caméra spéciale.

Sans vouloir te casser le moral, c'est un classique des limitations des convertisseurs USB/Ethernet bureautique.

Je pense que ton problème est difficilement soluble, d'ailleurs il me semble que ce n'est pas la première fois qu'on en parle ici ou en face :-)

Chris.

[bboulant 1]

Bonsoir,
juste quelques remarques:

1:le silex SX-3000GB est bien prévu pour supporter les liaisons isochrones, dixit le manuel et il y a une MAJ du firmware 1.0.2.
Il y a déjà une config avec une QSI-583-WSG + connexion à une monture Paramount à l'obs de Flagey

2:une webcam envoie un flux isochrone, une CCD je ne pense pas.

3:ton hub usb est bien alimenté ?

4:as tu essayé de brancher directement ta CCD sur le Silex, donc sans HUB voir s'il y a une différence

A+

[totolesbaloches 0]

Le Silex 3000 n'est pas vraiment une réussite !!!!

Le Silex 3000 ne marche pas avec un HUB usb, il faut connecté directement dessus.
Le Silex 2000 marche lui très bien avec un HUB USB, mais il est plus lent.

J'ai bien une QSI et la Paramount connectés sur le Silex 3000 mais sans HUB !! Et la ça marche très bien !
c'est pour cela que j'ai un 3000 pour le haut debit, et un 2000 pour le reste http://www.felopaul.com/schema.htm

Autre chose, il faut que le Silex 3000 ai une adresse IP fixe sur la même plage que ton pc et ne pas travailler en adresse MAC.

Autre chose le 2000 comme 3000 (deja dit plusieur fois) ne marchent pas en haut debit avec les DMK, donc a voir avec les autres cameras haut debit USB!

Laurent
www.felopaul.com

[Jean D 0]

Bonjour et merci pour ces retours...

@ Chris : un grand merci pour ces infos techniques...ça permet de mieux comprendre comment tout ça fonctionne !!! Mais une question que je me pose, est-ce qu'une CCD est réellement considérée comme périphérique isochrone ??? Comme BBoulant, je pensais que les caméras de surveillance, webcam,...faisaient partie de cette catégorie mais pas les CCD...

@ BBoulant : oui, la caméra CCD était bien branchée en direct sur le Silex...
Si je passe par un hub USB (même alimenté), elle n'est plus reconnue !!!
En ce qui concerne le firmware, il est bien à jour, j'ai la version 1.0.2.

@ Laurent : au niveau de la config, j'ai laissé le soft d'installation SX Virtual attribuer automatiquement l'IP du Silex...je pourrai t'en dire plus en fin de journée en ce qui concerne les paramètres utilisés.

Encore merci pour votre aide !!!

Bonne journée.

Jean

[CielProfond23 0]

Bonjour.

En général, tous les périphériques qui doivent répondre une grosse quantité de données dont ils ont l'initiative, en continu ou pas, essayent de profiter d'un mode isochrone.

Une webcam, un scanner par exemple, un DSLR en mode PTP par contre je ne sais pas.

Si le SILEX est réputé pouvoir travailler dans ce mode avec bonne version de firmware, alors c'est une bonne nouvelle!

Mais le flat "lissé régulièrement" que tu obtiens me laisse alors perplexe, c'est trop beau pour une perturbation du signal électronique par un HUB... Si c'est juste ça, tu as partie gagnée!

En fait, le fabriquant de la CCD peut décider de déclarer sont produit comme il le veut dans les classes USB existantes, voire même se définir sa propre classe de périphérique pour éviter toute tentative de prise en charge par un driver générique.

lsusb -v est ton ami :-) Sous linux bien entendu :-)

Chris.

[Lblanc 4]

Essaye une chose.
desinstalle ta camera, driver et cie et reinstalle le tout avec la cam branché sur le silex et non pas sur le pc.
pour moi ça avait changé la donne avec une webcam.

[Jean D 0]

Salut et merci pour votre aide...

@ Lblanc : voila, c'est fait...désinstallation des drivers de l'Atik, de SX Virtual...puis réinstallation de l'ensemble avec la caméra branchée sur le Silex. Rien ne change...

@ Chris : merci pour le complément d'info ...ahhh Linux...

@ Laurent : je suis allé chercher un max d'infos sur ma config...si tu vois quelque chose de louche... ...

Voici ce que ça donne :
System Status
=============
Host Name SX44AB20
IP Address 169.254.69.76(Link-Local)
Subnet Mask 0.0.0.0
Default Gateway 0.0.0.0
mDNS Service Name SX44AB20
mDNS Domain Name sx44ab20.local.
LAN Interface 1000Mbps Full-duplex
Primary WINS Server 0.0.0.0
Secondary WINS Server 0.0.0.0
NetBIOS Scope ID

MAC Address 00:80:92:44:AB:20
Firmware Version 1.0.2

Network Settings
================
Item Value Instruction
---- ----- -----------
Host Name SX44AB20 15 letters[max.]
DHCP/BOOTP Enable Select one
IP Address 0.0.0.0 IP address
Subnet Mask 0.0.0.0 IP address
Default Gateway 0.0.0.0 IP address
Network PnP Enable Select one
mDNS Enable Select one
mDNS Service Name SX44AB20 63 letters[max.]
LAN Interface AUTO Select one
Primary WINS Server 0.0.0.0 IP address
Secondary WINS Server 0.0.0.0 IP address
NetBIOS Scope ID 223 letters[max.]

Device Status
=============
USB Device Information
USB Device Manufacturer Name USB Speed Connected PC Duration (H:M:SEC)
PID[0xDF2C] VID[0x04B4] Full Speed 169.254.199.101 00:07:54

...et par IPconfig dans une fenêtre de commande :

Carte Ethernet Connexion au réseau local :
==========================================
Suffixe DNS propre à la connexion.......:
Adresse IPv6 de liaison locale..........: fe80::d0b4:345e:78cd:c765%12
Adresse d'autoconfiguration IPv4........: 169.254.199.101
Masque de sous-réseau...................: 255.255.0.0
Passerelle par défaut...................:

Voila voila...encore un grand merci pour vos infos !!!

Bonne soirée.

Jean

[CielProfond23 0]

Bonsoir.

J'enfile ma casquette d'ingé système... et réseau :-)

Bon, déjà tu as une configuration anormale qui montre une config automatique qui ne marche pas, ou alors avec énormément ce chance...

Et la chance en informatique, ca ne dure pas.

1) Un masque de réseau ne dois jamais être à 0.0.0.0 parce que celà a une signification très particulière. Là je ne rentre pas dans le détail, c'est vraiment technique. A corriger par un masque fixes /24, c'est à dire 255.255.255.0 en dur.

2) Tu as des adresses de type RFC1918 (169.254.x.y), c'est à dire des adresses non routables attribuées par le driver du périphérique qui n'a ni adresse IP fixe, ni n'a reçu d'adresse par un DHCP à qui il a demandé; A corriger par des IP fixes en dur.

3) Ton SILEX est sur un réseau, ton PC sur un autre (en classe C) MAIS tu as un masque de type /16 (classe B) donc ca pourrait marcher avec un peu de chance... voir plus haut.

Bref c'est le souk total.

Avant de te proposer une config simple, une question simple: est-ce que ce PC est destiné à être connecté à une BOX et doit avoir accès à internet ?

Est-ce qu'il l'a été pendant tes tests, ou avant ?

Chris.

[Jean D 0]

Salut Chris,

J'ai de la chance d'être tombé sur un pro !!!

Pour répondre à ta question, oui, le PC est en général connecté à une Livebox Mobistar (en WiFi ou en câblé directement sur la Box).

Lors des séances astro et en particulier lors des essais, ce n'était pas le cas...

Merci d'avance pour ton aide

Jean

[CielProfond23 0]

Et voila, bingo!

Quand tu fais fonctionner ton réseau (PC+SILEX ou autre) sans être connecté à la BOX, la config réseau ne peut pas se faire, parce que, dans un soucis de simplification grand public, c'est usuellement la BOX qui configure tout ce qui lui est connecté...

On dit qu'elle est serveur DHCP pour "Dynamic Host Configuration Protocol".

Le service DHCP, qui est une partie des fonctions techniques de la BOX, fournit les DNS ou les forwarders mDNS, les WINS, le hostname ou de la passerelle par défaut.

Ainsi un réseau familial, qui est prévu pour recevoir sa configuration d'une BOX, se trouve non configuré quand on le démarre SANS être connecté à la BOX: les matériels connectés (PC, imprimantes, SILEX) demandent leur config dans le vide mais rien ne répond, alors ils configurent par défaut des paramètres non fonctionnels qui ne perturberont pas les autres (169.254.x.y et 0.0.0.0 par exemple).

Normalement, quand on est pas spécialiste, on ne se soucie de rien: le PC démarre, il demande toute sa config à la BOX qui lui répond, ainsi fait aussi une imprimante réseau ou tout autre appareil qui démarre sur le réseau local.

Le problème survient quand on DOIT mettre une adresse IP FIXE sur un matériel et que l'on n'est pas connaisseur, c'est à dire décider d'une configuration pour un matériel sans lui laisser demander à la BOX ni laisser la BOX lui répondre.

C'est simple quand on est dans un réseau administré, mais dans le cas d'un réseau familial avec une BOX, ça peut devenir ennuyeux: il faut en même temps laisser la BOX servir de passerelle vers internet (c'est son role) mais en même temps faire en sorte que des matériels ne demandent pas une config mais utilisent une config manuelle compatible.

La BOX ne pouvant pas être reconfigurée puisqu'elle est un équippement du FAI, il faut la considérer comme le coeur du réseau local.

On peut résumer le tableau ainsi:

1) Il faut que la BOX soit sur le réseau, ainsi elle permet l'accès à internet;

2) On peut laisser la BOX configurer certains matériels, mais pas tous, ou même aucun.

3) Il faut pourtant que les configurations manuelles que nous allons mettre soient compatibles avec les configurations automatiques envoyées par la BOX, les seules avec les quelles elle peut fonctionner;

Nous allons procéder en deux temps:

1) Laissons la BOX branchée, laissons le réseau démarrer, et assurons-nous que tout fonctionne, en papotant sur http://www.astrosurf.com par exemple :-)

2) A CE MOMENT LA, relevons la configuration réseau comme tu l'as fait, mais nous verrons qu'elle est très différente et cohérente: ce sera ce qu'on appelle "le plan d'adressage" du réseau sur lequel la BOX fonctionne, puisqu'elle aura tout configuré comme elle l'entend;

3) Avec ces informations issues de cet "espionnage" nous allons recréer de toute pièce des configurations MANUELLES qui seront compatibles mais qui ne changeront pas et qui résoudrons certains problèmes;

La suite au prochain message :-)

Chris.

[CielProfond23 0]

Et la suite :-)

Une fois que tu auras collecté ton plan d'adressage tel qu'il est normalement configuré sur ton réseau local par ta BOX, on va s'en servir pour créer des configurations manuelles compatibles.

Bien entendu, l'un des avantages de se passer de DHCP c'est que tout fonctionnera pareillement, avec ou sans box connectée!

Si la BOX est sur le réseau, l'accès à internet est possible, si tout le bastringue est en vadrouille, tout fonctionnera aussi entre les matériels connectés MAIS sans accès internet.

ATTENTION, ne diffuses pas ici ton plan d'adressage réel, envoies-le moi par les administrateurs, je te dirai ensuite comment faire en perso.

Chris.

[Jean D 0]

Voila Chris,

Les infos sont envoyées.

A bientôt pour la suite...
...et encore merci !!!

Jean

[Bec à Fuel 0]

Il faudrait déjà configurer la box pour qu'elle donne ses baux DHCP sur un réseau de classe C : 192.168.x.y
Ca résoudrait pas mal de soucis, déjà. Non ?

Maintenant, je suis également d'avis de tout mettre en IP fixe, c'est bien plus simple à gérer, surtout sur un petit réseau familial.

Là encore, y a le choix :
- laisser le DHCP actif sur la box mais en assignant des adresses fixes selon les adresses MAC des périphériques, ainsi la box donnera toujours la même adresse au même périphérique
- désactiver le DHCP sur la box et renseigner à la main les adresses sur chaque périphérique (adresse IP, masque et passerelle)

La première solution a le mérite de l'élégance et de la rationnalité. La box (le routeur, donc) gère complètement l'adressage et il n'y a aucune action manuelle sur les périphériques.

Perso, je prendrais quand même la deuxième solution. De cette façon, c'est "toi" qui maitrise ton plan d'adressage. Les mains dans le camboui, y a que ça de vrai
Revers de la médaille : à chaque ajout de nouveau périphérique sur le réseau, il faut le configurer à la main... Mais comme c'est pas tous les jours qu'on fait ça, c'est pas un drame non plus.

Tiré de : "Le réseau c'est simple", en 143 volumes

[CielProfond23 0]

Bonjour.

En général, les DHCP lease ne sont pas modifiables sur les BOX grand public, mais même si c'est le cas et que tu choisis un RFC1918 plus adapté à ce que tu veux, ca reste quand même centré sur la présence ou non de la BOX sur le LAN.

De plus il faut déterminer si la BOX est en bridge ou en routeur.

C'est pourquoi je préconise aussi des configs manuelles dans le plan d'adressage initial de la BOX.

De plus, laisser la BOX en serveur DHCP va rendre le réseau inopérant quand elle ne sera pas branchée, ce qui semble le cas en "mode astram".

Je récupèrerai le plan d'adressage dans la journée.

Chris.

[Bec à Fuel 0]

D'accord pour tout. C'est bien pour ça qu'il vaut mieux des configs en IP fixes, selon moi.
En plus, ça permet de mieux comprendre ce qui se passe, même en n'étant pas un spécialiste.

Juste un mot à propos des box : ça parait étonnant qu'elles puissent être en mode bridge par défaut, non ? Surtout vu leur destination initiale, les particuliers.

[CielProfond23 0]

Bonjour.

Les FreeBOX sont en bridge par défaut, avec un DHCP externe pour donner au PC l'IP publique de la ligne et les DNS.

Ce sont les seules BOX à ma connaissance qui sont complètement configurables une fois que tu as basculé en mode routeur qui n'est pas par défaut.

Perso je l'utilise en bridge avec en frontal un firewall ROMé(M0n0wall).

Chris.

[Bec à Fuel 0]

Ah oui, c'est vrai, pour les Freebox ! Je ne m'en rappelais plus alors que j'en utilise une sur mon réseau...

A gauche, c'est Orange et à droite c'est Free.

[Ce message a été modifié par Bec à Fuel (Édité le 17-11-2010).]

[Jean D 0]

Salut,

@ Bec à Fuel : merci pour les infos...et comme tu le dis, y a plus qu'à mettre les mains dans le cambouis !!!

@ Chris : as-tu bien reçu les infos ? Quand tu dis de les envoyer via les Admins, c'est en leur envoyant un mail (ce que j'ai fait)qu'ils te transfèreront par la suite...ou alors il y a une autre procédure à côté de laquelle je serais passé ?!...

Merci et bonne journée...

Jean

[CielProfond23 0]

Bonjour.

Non, rien reçu pour le moment. Pas grave, ca viendra à point nommé.

Chris.