Bonjour à toutes et à tous !
Ma question est la suivante :
Est-il possible de calculer la distance entre deux µC reliées entre eux par une liaison RS485 ?
J'ai pensé à un "ping" et calculer la distance en fonction du temps de réponse, mais je ne sais pas si cela peut s'appliquer.
Qu'en pensez vous ?
Mesurer la longueur du câble .....Envoyé par pedrosky
J'aime pas le Grec
Alors ça, je n'y avais pas pensé, comme quoi...
vu qu'une 485 ne peut pas aller bien loin..... (quoique plus qu'une 232)
c'est évidemment la bonne soluce
Pour répondre à ta question : pas évident
... sauf erreur de ma part, ton signal fait 273m en 1us ...
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
bonsoir
Meme avec un MCU cadencé à 20x4=80Mhz cycle de 50nS
en supposant qu'une entree Timer puisse suivre .. resolution > 13 Metres /cycle
et que le cable n'est pas sur un Touret ou enroulé (bobine)..
ou via la capacité du cable xpF/metre et la mesure via un MCTU ?
Je souhaite utiliser des Raspberry b+ comme microcontroleur.
Le processeur est cadencé à 700MHz, la précision pourra être meilleure non ?
Que veut tu dire par une entrée timer qui puisse suivre ?
Tu as un lien WEB sur ce µC formule I ?
J'aime pas le Grec
Bien sur : http://www.ldlc.com/fiche/PB00172383.html
http://www.framboise314.fr/ce-qui-ch...y-pi-modele-b/
Bonsoir,
Hum hum c'est pas gagné, les résistances d'adaptation d'impédance placées en bouts de ligne risquent justement d'empêcher toute réflectométrie, non..?!
Leonardo était ingénieur "sans papier", et moi diplômé juste...technicien...
à 80MHz comme FOSC sur un PIC, le circuit d'entree du timer a un temps de reponse tel,qu'on ne peut depasser 50Mhz
en comptage externe..
à 700MHz , horloge primaire, mais quel est le cycle des I/O (entree/sorties), surement bien moins.
Je pensais retourner une réponse du µC esclave au maitre, et calculer la distance à partir de ce retour.
Je ne sais pas. Es-ce lié à la vitesse de transition du protocole rs485 qui lui est bridé ?
La RS485 n'est pas un protocole. Et en quoi la RS485 est-elle bridée?
Mesurer la distance du câble à l'aide d'un µC me semble utopique car comme il s'agit de logique programmée, on ne maitrise pas vraiment les timings. A la réception par exemple, il va falloir que le périphérique détecte un changement d'état de la ligne pour envoyer une interruption. Le temps de prise en compte de l'interruption n'est pas déterministe: y a-t-il une interruption en cours?, l'instruction en cours est-elle en début de traitement, en fin de traitement? Est-ce une instruction de saut, auquel cas, même avec un processeur RISC, elle peut prendre plus de temps à s'exécuter, le temps de sauvegarde du contexte avant le branchement au programme d'interruption est-il constant?, etc..
Un FPGA ou de la logique câblée classique fera cette mesure bien mieux que n'importe quel µC.
Oui tu as raison Jack, c'est moi qui confond.
RS485 est une norme, et je souhaite utiliser une trame UART pour communiquer entre les deux Raspberry, qui elle aura une vitesse de transmission bridée.
Pour le calcul de la distance entre l'µC maitre et l'µC esclave, je souhaite envoyer une trame avec une demande de retour ("ping"). Lors de cette demande, il n'y aura aucune instruction en cours.
Je regarde le FPGA et la logique câblée.
Merci à tous pour votre aide.
Dernière modification par pedrosky ; 11/11/2014 à 18h05.
Quelle est l’intérêt de calculer la distance entre les deux µC ????? Sachant que la mesure par le temps de propagation A/R de la trame est une douce utopie ....
J'aime pas le Grec
Pourquoi es-ce une utopie ?
Si on connait la vitesse de propagation d'une ligne et le temps que met le raspberry à recevoir et retourner la réponse (qui est fixe non ?) on peut facilement calculer le temps de propagation total et en déduire la distance entre les 2 raspberry ?
Je me trompe peut-être, il y a surement des paramètres à inclure et que je ne connais pas.
Il serait en effet intéressant de connaitre les raisons de cette nécessite de connaitre la distance entre les 2 cartes.
Bah non justement ... et ce temps de latence va représenter environ 99.9% de ta mesure finale ...
Dans quelles conditions tu veux faire la mesure : une fois à l'installation ou toutes les 10 minutes ? ... si c'est toutes les 10 minutes, tu câble un fil en plus (et en parrallèle), tu fais une impulsion sur ce fil et tu mesure le temps de propagation ... un ping n'est pas fait pour ça et ne peut pas fonctionner (surtout pas sur un rPi sous Linux)
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
J'étudie un projet de contrôle de faisceaux lasers à distance, pour une application de spectacle son et lumière.
Plus précisément, je souhaite diriger en simultané des lasers très éloignés de l'ordre du Km.
Je souhaite utiliser des Raspberry b+ pour faire l'interface et une liaison RS485 paire torsadée entres chaques.
Il y aurai un maître avec un pupitre, et des esclaves reliés aux lasers.
Le souhait de connaitre la distance entres chaque, c'est le petit plus qui me permettrai de visualiser sur mon pupitre la distance et le positionnement de chaque lasers sur la ligne.
Cela n'est en aucun cas obligatoire sur mon projet, mais ça m'intéresse quand même.
Tu as 100m de cable . Le temps aller/retour, c'est , au pif, 200x3ns =600ns .... comment tu vas mesurer ce temps sachant que la réactivité des UART est de plusieurs microsecondes ???? Faut revenir les pieds sur terre ......
J'aime pas le Grec
Hello,
Avec un bon oscilloscope
https://www.youtube.com/watch?v=Il_eju4D_TM
Ca peut fonctionner sans oscillo : deux comparateurs, un compteur en ns ???
La magie des lignes de transmission.
Biname
Pour un son et lumière tu cherche à synchroniser un truc avec une précision < 1us ...... il faudra alors aussi tenir compte du temps de propagation de la lumière des lasers jusqu’au spectateur ... sans parler du son ...
sans parler de la mécanique de tes laser qui va de toute façon ajouter 100000x plus d'erreur ...
Dernière modification par Seb.26 ; 11/11/2014 à 19h10.
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Ok Seb.26, je pense que j'ai ma réponse.
Je pensais à tord que le temps de réponse du raspberry serai fixe.
J'aurai souhaité faire cette mesure une fois à l'installation. Ce n'est donc pas possible.
Tant pis !
De plus, la longueur du cable n'est pas forcément égale à la distance entre les 2 systèmes: la liaison ne ne fait pas forcément en ligne droite, si on utilise un touret pour le câble coaxial, il ne faut pas tenir compte de la longueur du câble encore enroulé.
Et n'y a-t-il pas moyen d'utiliser les laser pour faire de la triangulation..?
Leonardo était ingénieur "sans papier", et moi diplômé juste...technicien...
Bonsoir,
un petit rappel : la resolution d'une mesure est directement corrélée au pas de l'appareil de mesure, ici avec une 485 @ 10MHZ(soyons fous) la résolution sera de 50ns au mieux (je suis très gentil je suppose que l’émission n'introduit aucune latence et que la réception se synchronise en 1/2 bit) donc environ 15 m, comme la fréquence sera plutôt de l'ordre de la centaine de KHz au max on aura 150m !!
Il serait judicieux de se renseigner sur le fonctionnement et le schéma/VHDL d'une interface série.
conclusion : On ne peut pas faire de réflectométrie avec un UART fut il en 485.
JR
l'électronique c'est pas du vaudou!
C'est inutile de vouloir synchroniser son et lumière avec une précision < 1us. 1ms c'est déjà très très bien. En entendant son propre retour avec 1ms, un musicien peut jouer sans aucune gêne, c'est dire. N'oublie pas que des spectateurs situés disons à 30 mètres de la source ressentiront déjà un décalage de 100ms. Alors bon... Peut-être faudrait-il redéfinir le besoin.
Salut,
Peut-être synchroniser les deux cartes sur ethernet PTP?
A+
