ABCelectronique : portail d'information dans le domaine de l'électronique
Home » Diverses rubriques » Archive forum sujets+corp
 
     
   Moniteur Sony CPD-1704 S  
A la mise sous tension la led veille , s'allume une seconde puis s'éteind.
On entend un sifflement, et c'est tout ! Ecran noir ensuite !
Je n'a pas le shéma, quelqu'un peut il m'aider à localiser la panne !

Merci par avance

Un gars du sud ;o)


Numéro de l'article: 56603   |  De: Francois34   |  Date: 2003-11-07 20:12:49
   RE: Moniteur Sony CPD-1704 S
il y a de grandes chences que le transfo tht soit en cc .
1 pour etre sur , dessoudez le transistor de puissance tht, vérifiez s'il est en cc.
si c'est le cas le remplacer

2 dessouder la tht et rallumez , on ne doit plus entendre le sifflement .

Numéro de l'article: 56771   |  De: jl   |  Date: 2003-11-09 18:17:55
   RE: Moniteur Sony CPD-1704 S
Bonjour
Remplacer le petit condensateur chimique C 911 situé au primaire de l’alimentation et votre problème devrait être résolu ( c’est une panne typique sur ce modèle )

Dominique.


Numéro de l'article: 56925   |  De: dom   |  Date: 2003-11-10 19:55:43

   Quelle classe d'amplificateur ?  
Bonsoir !


A quelle classe d'amplificateur , appartient le schéma visible a l'adresse suivante ?

http://xoomer.virgilio.it/fladelle/Page2.htm



A?; AB ? ...


Merci et bonne soirée !

Numéro de l'article: 56605   |  De: Tronic-man   |  Date: 2003-11-07 21:53:21
   RE: Quelle classe d'amplificateur ?
Salut, moi je pense a un ampli de classe A, car les amplis de classe A, ont une puissance moins elevée que la classe AB, mais la classe A, a une distorsion plus faible que la classe AB donc de mélior qualité.
Bonne soirée
nico

Numéro de l'article: 56609   |  De: nicolas   |  Date: 2003-11-07 22:49:42
   RE: Quelle classe d'amplificateur ?
Salut,
Rappel, sans courant de repos dans les fets ce serait un 'classe B'donc avec distorsions qui sont toujours à réduire !
Comme indiqué dans la 'Note', par R11 régler I drain à 100mA, donc c'est un ampli classe A.
cd


Numéro de l'article: 56610   |  De: cd   |  Date: 2003-11-07 22:57:58
   RE: Quelle classe d'amplificateur ?
Salut,
Classe AB traditionnel.


Numéro de l'article: 56617   |  De: popelix   |  Date: 2003-11-08 02:20:33
   RE: Quelle classe d'amplificateur ?
...Classe "A" ou "AB" alors ?

je penche plus vers "A" comme "cd" la dit, mais "popelix" dit "AB"...je suis un peut perdu, je suis qu'un amateur...

vous pouvez confirmer, que c'est un classe "A" ?...

Si donc, c'est effectivement un classe "A", c'est un ampli de très bonne qualité, je pense !

Encore merci...


Numéro de l'article: 56627   |  De: Tronic-man   |  Date: 2003-11-08 09:44:05
   RE: Quelle classe d'amplificateur ?
Salut

Classe AB selon réglage / R11. (Avec 100 mA de courant)

A+

Numéro de l'article: 56631   |  De: SuperPapum   |  Date: 2003-11-08 10:51:36
   RE: Quelle classe d'amplificateur ?
ok ,merci.

Numéro de l'article: 56632   |  De: Tronic-man   |  Date: 2003-11-08 10:54:19
   RE: Quelle classe d'amplificateur ?
Salut,
C'est un classe AB.
@+

Numéro de l'article: 56634   |  De: Zell   |  Date: 2003-11-08 11:00:01
   RE: Quelle classe d'amplificateur ?
merci.

Numéro de l'article: 56686   |  De: Tronic-man   |  Date: 2003-11-08 21:38:53
   RE: Quelle classe d'amplificateur ?
Bonjour

C'est un classe AB

A bientôt

Numéro de l'article: 56694   |  De: EPERVIER   |  Date: 2003-11-08 22:01:41
   RE: Quelle classe d'amplificateur ?
salut d'apres ces caractristiques ca ma l'air d'un amplificateur de bonne qualité.
je me trompe??

+++

Numéro de l'article: 56741   |  De: lolo56   |  Date: 2003-11-09 13:46:04
   RE: Quelle classe d'amplificateur ?
c un classe AB. Car c un push-pull avec polarisation


Numéro de l'article: 56795   |  De: FABRICE   |  Date: 2003-11-09 20:25:27

   Panne sur TV sony KV-X2540B(AE1C)  
A le mise sous tension la led rouge s'allume une fois et s'eteint puis plus rien merci d'avance

Numéro de l'article: 56606   |  De: roland   |  Date: 2003-11-07 21:56:27
   RE: Panne sur TV sony KV-X2540B(AE1C)
lorsque la led sallume et que la led marche arret la panne est situer en alim primaire change les condo pret du radiateur d'alim a plus.


marc

Numéro de l'article: 56665   |  De: bathedou   |  Date: 2003-11-08 17:36:29
   RE: Panne sur TV sony KV-X2540B(AE1C)
Salut, par hasard vous n'auriez pas un schema ?

Numéro de l'article: 57068   |  De: boblaiponge   |  Date: 2003-11-11 22:50:24

   recherche dissipateur peigne  
Salut,

Je recherche un dissipateur "peigne" du même genre que celui-ci:

http://www.radiospares.fr/cgi-bin/bv/browse/Module.jsp?BV_SessionID=@@@@1919567879.1068239723@@@@&BV_EngineID=ccccadcjkjjhekdcfngcfkmdgkldfhf.0&cacheID=f1ie&3245692905=3245692905&catoid=-951358251

Le problème c'est que ce profilé n'est vendu qu'en morceau de 1m et vu le prix!!
Alors si parmis vos stocks de recup vous avez un bout de profilé de dimensions approchées à celui ci en longeur de 5 à 10cm, je suis interessé.
Contactez moi: ******************
Merci
MANU

Numéro de l'article: 56607   |  De: MANU   |  Date: 2003-11-07 22:33:00
   RE: recherche dissipateur peigne
Mets voir plutôt la référence de ce profilé.
Le lien est périmé.

Numéro de l'article: 57017   |  De: Fas54   |  Date: 2003-11-11 16:35:08

   ideflasher...?  
salut a tous le monde

je voudrais savoir si quelqun connait ca :

http://www.loet.de/flasher_en.html

http://www.loet.de/images/ideflasherSchematic.gif

et si quelqun a le typons de ce circuit ?



amicalement !


Numéro de l'article: 56608   |  De: toi-mon-toi   |  Date: 2003-11-07 22:47:02

   Ch info sur protocole de lecture sur une SIM card  
Salut a tous...

je cherche actuellement des infos (textuelle, site, ou autre) sur le protocole de communication à utiliser pour faire une sauvegarde du phonebook d'une SIM (dont je connais le code PIN bien entendu...)


J'ai a ma dispo un socket de connection, un port // de PC avec tout ce qui faut pour dialoguer par ce dernier, pis un pic 16F84 au cas ou le timing serait serré (ce que je crois)...
Et je peux aussi faire dialoguer le pic en serie vers un port du même accabit...
J'ai aussi un programmateur Apollo pour Fun et Cie, qui pourrait peut etre servir, mais avec un micro controlleur propriétaire et non documenté...


Numéro de l'article: 56611   |  De: Guillaume   |  Date: 2003-11-07 23:41:11

   comment tester un quartz?  
salut

exite t il un montage ?

merci d avance

@+

Numéro de l'article: 56613   |  De: fthi   |  Date: 2003-11-07 23:56:59
   RE: comment tester un quartz?
Salut !

ben si tu as un pic genre 16f84 tu ecris un petit programme qui te sort un signal carré (sous multiple de la frequence F/4 de ton Quartz, pis tu ecoute la frequence de sortie...
ca te donnera une idée...

M'enfin y'a peut surement plus simple...

Numéro de l'article: 56614   |  De: Guillaume   |  Date: 2003-11-08 00:15:48
   RE: comment tester un quartz?
Bonjour,

Faut savoir aussi utiliser Google ! Une recherche avec testeur+quartz donne de multiples adresses dont celle-ci :
http://membres.lycos.fr/pjacquet/quartz.htm

André01


Numéro de l'article: 56625   |  De: André01   |  Date: 2003-11-08 09:11:40
   RE: comment tester un quartz?
Salut

j' ai aussi cela :
http://etronics.free.fr/montages/mesure/AME02.htm

@+++ dan

Numéro de l'article: 56693   |  De: dan   |  Date: 2003-11-08 21:57:12

   choix d'un transistor MOSFET  
bonjour,

Je suis à la recherche d'un transistor MOSFET canal P destiné à couper l'alimentation 500ma d'un circuit alimenté par l'USB afin de pouvoir activer la com USB avec une conso qui doit rester <100mA.

Je cherche donc un MOSFET canalP :
-capable de passer facilement les 500mA
-Capable de passer ce courant avec une faible resitance ON et ce avec -5V de tension grille source seulement (on appele ca MOSFET à commande logique non ?)
-en boitier SOT223
-super courant (trouvable "partout", radiospares si possible, je dois leur faire une commande bientot...)
-et concu pour ce genre de fonction (commutation d'alim)

Vous devez vous dire "cherche dans les docs pour trouver ton bonheur, demerde toi !"...En fait, j'ai bien cherché et j'ai bien trouvé des transistors que je crois capable de ce que je veux (un paquet meme), mais ils sont tous fait pour des fonctions bisaroides que je ne connais meme pas (driver de ci ou commutation de ca...) et je suis finalement jamais sur de mon coup...surtout que les prix vont du simple au sextuple pour des performances qui, suivant mes critères, semblent les memes :-((

merci d'avance pour vos propositions de ref ou pour vos conseils, critères et techniques de choix


Numéro de l'article: 56618   |  De: petitours   |  Date: 2003-11-08 02:43:33

   prog in situe des 68HC908  
bonjour,

Je me suis mis depuis quelques temps aux 68HC908 avec grande satisfaction car cette gamme tres riche et large de microcontroleurs est pas chère, tres puissante et facile d'utilisation...
Je les programme avec un programmateur inspiré de celui decrit sur le jeune mais déjà superbe site de YBdesign www.le68HC908.fr.st
Avec ce programmateur, on met le 68HC908 dans un support, on le programme, puis on le retire pour le placer ensuite sur sa carte définitive.
Quand on utilise un petit "monstre" à 64 pattes au format cms QFP comment fait on pour le programmer ou reprogrammer puisque on ne peut le retirer de sa carte ?
Comment gère on toutes ces lignes "condamnées" pour la programmation ?
Comment fait on si on utilise un quartz à 16MHz pour l'appli alors qu'il faut 4.915 ou 9.83 MHz pour la prog ?

merci d'avance

Numéro de l'article: 56619   |  De: petitours   |  Date: 2003-11-08 03:03:56
   RE: prog in situe des 68HC908
salut.
pour le programmer tu doit passer en monitor mode. Dans la doc de ton micro il doit y avoir tout les détail pour le configurer, en suite cela depand du materiel que tu possède:

si tu as une mon08 multilink ou cyclone (p&e microelectronics) c'est tout simple tu l'as branche sur les broche du micro et tu utilise le logiciel fournie.

sinon il existe plusieur instructions en monitor mode qui te permettent de programmer la flash (write, read,iwrite...) les instruction et les donné sont transmise en serie sur une broche est il te faut donc une petite interface pour adapter les niveaux rs232 vers le micro.

donne moi + de détail sur ton materiel.

je comprend pas les lignes "condamnées" pour la programation??

Le quartz ne gene pas tu peut utiliser un quartz 16Mhz je l'est déja fait.

Numéro de l'article: 58886   |  De: seb   |  Date: 2003-11-24 21:57:14

   Probleme TV DUAL Star2000: code parental  
Bonjour, j'ai un soucis avec mon téléviseur, faisant des essaie pour la reception de l'image de mon ordi j'ai appué par erreur sur le verrouillage parentale du televiseur. n'ayant jamais rentré ce code qui est celui d'origine sur mon televiseur DUAL Star2000, qq'un a t il une idée sur comment pouvoir le deverrouiller ?
désolé pour l'apparté et merci...

Numéro de l'article: 56621   |  De: NRH   |  Date: 2003-11-08 06:26:46
   RE: Probleme TV
essaye un code du genre 0000

Numéro de l'article: 56623   |  De: frederic   |  Date: 2003-11-08 08:11:22
    Probleme TV
J'espère que vous avez pu réparer, nous sommes le 3 décembre.
La technologie c'est super mais quand ça déconne on est plus qu'emmerdé.
J'ai le meme problème de verrouillage et la meme non-volonté de verrouiller sur un téléviseue BLAUPUNKT.
salut

Numéro de l'article: 60102   |  De: COSSARD   |  Date: 2003-12-04 11:33:13

   Liaison série bi directionnelle  
Bonjour à tous,

Je souhaite mettre en oeuvre une liaison série bi directionnelle en RS485. Le but est de faire dialoguer plusieurs cartes électroniques en mode multi-maître. (Je voudrais éviter le bus I²C qui ne possède pas assez d'adresses)

Si vous avez des idées de protocole, surtout n'hésitez pas.
Merci beaucoup

Frédéric

Numéro de l'article: 56622   |  De: frederic   |  Date: 2003-11-08 08:10:36
   RE: Liaison série bi directionnelle
Cela ne te suffit 128 ?

Olivier

Numéro de l'article: 56629   |  De: gemiolac   |  Date: 2003-11-08 10:40:14
   RE: Liaison série bi directionnelle
Ben non, il faut câbler un atelier de production entier. Pour commencer, il s'agit de contrôler l'accès à des zaones de travail (5 pour l'instant).

A l'avenir, il faudrait pouvoir étendre ce bus à tout l'atelier pour contrôler le fonctionnement depuis un moniteur (de surveillance).

Ce projet est très sérieux car il s'agit de ne pas dépenser 1500euro par contrôleur de porte (prix chez Siemens) ou par moniteur de machine

En attendant, 128 sera suffisant mais il faut que je songe dès à présent à l'extension du bus.

Peux-tu m'en dire un peu plus surles protocoles des bus de terrain genre CAN ou profibus???

Numéro de l'article: 56676   |  De: frederic   |  Date: 2003-11-08 19:01:51
   RE: Liaison série bi directionnelle
sur
http://xavier.fenard.free.fr/Reseau%20RS485.htm
il y a deja des morceaux...
XF

Numéro de l'article: 56708   |  De: XF   |  Date: 2003-11-08 23:51:20
   RE: Liaison série bi directionnelle
Salut
------

Laisse tomber le RS485 et passe au CAN.
LE RS485 va te nécessiter un maître de bus, ou un protocole de communication compliqué, un seul interlocuteur peut parler en même temps, ce qui n'est pas le cas du CAN.

Tu as le schéma et le logiciel d'un convertisseur CAN/RS232 sur mon site, rubrique "domocan".

A+
Bigonoff


Numéro de l'article: 56833   |  De: Bigonoff   |  Date: 2003-11-10 02:10:17
   RE: Liaison série bi directionnelle
Le CAN est pour l'automobile, on ne passe pas de données dessus, seulement des mesures,en CAN il n'y a pas d'AR. En clair, si l'info pression huile est perdu, c'est pas grave, elle sera retransmise dans la seconde suivante. Par contre perdre qq octets dans un fichier c'est une catastrophe. Le mieux c'est de mettre en RS485 le protocole OM AX25. En clair RS485: niveau0 (hard) le protocole X25 (niveau1 iso) garantie une transmission OK, des sources existent.
Les radio amateurs (OM) utilisent le protocole, evidement en HF!!. Et la un fichier (des donnees)de l'autre bout de la terre arrivera (bon il faudra un routeur niveau 3). Sur une installation simple: un seul bus, le routeur n'est pas necessaire. Sinon, les cartes ethernets mais le soft n'est pas gratuit, et ce sont des boites noires...mais 100Mbit/s.
Performance souhaitee?

XF

Numéro de l'article: 56973   |  De: XF   |  Date: 2003-11-11 11:14:02
   RE: Liaison série bi directionnelle
bonjour...pourquoi ne pas travailer en hf ....multimodulation...f1,f2,f3 etc...a+

Numéro de l'article: 56974   |  De: hacene   |  Date: 2003-11-11 11:27:20
   RE: Liaison série bi directionnelle
Pour la simple raison que c'est un milieu industriel ou des machines de découpe au laser travaillent en continu et que cela provoque assez de parasites EM. De plus, il faudrait une portée trop importante et passer à travers les murs.

Merci pour l'idée

Numéro de l'article: 56983   |  De: frederic   |  Date: 2003-11-11 12:44:51
   RE: Liaison série bi directionnelle
Je ne fais pas transiter des fichiers complets mais seulement des paramètres. Pour l'instant, je voudrais connecter des contrôleurs de portes (il faut juste transmettre les logs) puuis plus tard, on pourrait faire de la surveillance d'atelier en faisant transiter des paramètres tels que "Machine en production", "Machine en Panne", etc.

Le CAN me parait une bonne idée.

Numéro de l'article: 56984   |  De: frederic   |  Date: 2003-11-11 12:47:07
   RE: Liaison série bi directionnelle
Merci, je télécharge les fiches correspondantes et je te tiens au courant si le projet débouche (ce qui ne dépend pas de moi...)

Merci

Numéro de l'article: 56985   |  De: frederic   |  Date: 2003-11-11 12:48:12
   RE: Liaison série bi directionnelle
Effectivement, c'est le genre de réseau qu'il me faudrait. Merci

Numéro de l'article: 56986   |  De: frederic   |  Date: 2003-11-11 12:50:32
   RE: Liaison série bi directionnelle
Effectivementy, c'est ce genre de réseau qu'il me faudrait, Merci XF

Numéro de l'article: 56987   |  De: frederic   |  Date: 2003-11-11 12:52:02
   RE: Liaison série bi directionnelle
Attention le CAN ne garantie pas la suite des donnees.. c'est pas grave si une erreur n'entraine pas de consequence, mais sur une machine numerique.... un paquet de perdu et ca perce a cote de la plaque.
XF



Numéro de l'article: 57029   |  De: XF   |  Date: 2003-11-11 17:29:54
   RE: Liaison série bi directionnelle
Salut
------

Eh, XF, faut arrêter de raconter n'importe quoi!
Le CAN est ultra-sécurisé, avec CRC inclus, répétition automatique des données, trames d'erreurs.

Si tu veux tester mon bootloader CAN (sur mon site) tu verras si tu perds des octets.

Le CAN garantit comme les autres la suite des données, tout dépend de la façon dont on met en oeuvre. Ton raisonnement est erroné. On peut numéroter les paquets, on peut aussi travailler avec un seul registre d'émission qui ne se libère que si la trame est correctement reçue par tous les destinataires. L'accusé de réception est automatique et intégré dans le protocole CAN.

Je doute que dans une F1, ou sur un ABS, on se dise : "j'ai perdu des données, ce n'est pas grave, on me les renverra plus tard".
LOL.

Et dire : "on ne passe pas des données, on ne passe que des mesures", ça ne veut rien dire du tout. Tu devrais étudier attentivement le CAN, ta vision est un peu réduite à ce sujet.

A+
Bigonoff


Numéro de l'article: 57078   |  De: Bigonoff   |  Date: 2003-11-12 01:29:22
   RE: Liaison série bi directionnelle
En général, cetype de réseau a été pensé à l'avance, on n'a jamais vu un réseau concu pour perdre des informations en route. On s'arrange toujours pour les transmettre en entier

Numéro de l'article: 57123   |  De: frederic   |  Date: 2003-11-12 13:52:42
   RE: Liaison série bi directionnelle
Desole, je maintien evidement TOUT. OUI on peut numeroter les paquets, declencher une retransmission etc... c'est la norme X25. Effectivement il y a un CRC, mais quand il est rejete (par un recepteur) l'emetteur ne le sait pas, donc l'info est perdu cf norme CAN. Dans la norme Auto destiné a la remise a jour du soft du calculateur de bord on ajoute au CAN le X25, d'ou 2 octets "utiles" par paquet CAN, et un temps de mise a jour des calculateur....
Le CAN sic "les motoristes" est un multiplexeur, il evite les fils (jauges, compte tours...) donc l'info (paquet CAN) recu doit etre bonne (le CRC CAN) mais si on en loupe une.. pas grave.
Quand au systeme de collision avec priorite (CAN), qu'elle est la roue la plus prioritaire dans l'ABS? ...Le cafouillage des voitures avec ABS, d'ou un second reseau CAN... Heureusement que les avions de chasse( qui n'aiment pas les cables= poids)n'utilisent pas le CAN... Mais ARING bus a time slots, avec un maitre... defaut? son prix!!.
A noter que le nouveau BUS AUTO LIN utilise un maitre.
Mon but n'est pas de detruire le CAN, mais de dire pourquoi il a ete faite: du multiplexage de signaux, pas plus pas moins.
La transmission de donnes sans rien perdre (X25) est d'autant efficace que le paquet est gros (DATA/ENCAPSULAGE>>>), CAN: paquetbrut =8!!
XF





Numéro de l'article: 57148   |  De: XF   |  Date: 2003-11-12 17:49:29
   RE: Liaison série bi directionnelle
Salut
-----

XF, tu t'obstines à dire n'importe quoi.

Tout d'abord ce que tu dis sur le CAN est faux : si on a une erreur de CRC sur un récepteur, une trame d'erreur est envoyée automatiquement à l'émetteur, qui réenvoie le message tout aussi automatiquement.

Ca n'exite pas en RS 485. J'utilise le CAN pour des applications commerciales, et je sais comment il travaille. J'utilise également le RS485, et je connais les différences à l'utilisation pratique (entend la réalisation des cartes et des logiciels embarqués).

Les trames "loupées", c'est n'importe quoi. Le CAN est très très sécurisé à ce sujet, alors que le RS485 ne dispose d'aucun mécanisme (ni accusé de réception, ni trames d'erreurs, ni CRC). Donc, on doit tout gérer par soft, par exemple un accusé de réception. Rien n'empêche, bien que ce soit inutile, de faire un accusé de réception supplémentaire sur CAN en soft pour confirmer la commande. Qui peut le plus peut le moins. Le CAN ne perd pas des trames, c'est n'importe quoi. Du reste, qui voudrait d'un bus qui perd des informations?

Tes informations concernant la priorité des roues est louphoque. On travaille par messages, pas par adressage d'une carte. Donc, on peut envoyer le même message à plusieurs cartes simultanément.

Le sujet de départ était la réalisation d'un bus de terrain permettant de faire dialoguer plusieurs cartes électroniques. Le CAN est précisément destiné à ça, quoi que tu en dises.

Effectivement, la taille des octets est limitée à 8, car le CAN est un bus de terrain destiné à envoyer très rapidement des trames courtes, ce qui est tout à fait le cas lorsqu'on dialogue entre plusieurs cartes électroniques. En plus, la question initiale précisait qu'on désirait un mode multimaître, donc tout à fait conforme au bus CAN. Note que, à l'opposé de ce que tu dis, et étant donné le CRC codé sur 24 bits, la sécurité est d'autant plus grande que le nombre d'octets est faible (car on risque moins d'erreurs multiples qui s'annulent).

Voici un copier/coller de la traduction d'un document officiel de chez Bosh (inventeur du bus CAN). Note, et ce n'est pas moi qui le dit, le "haut taux de fiabilité", le "mode multimaître", et la "détection des erreurs", ainsi que la "retransmission automatique des messages". Soit tout le contraire de ce que tu affirmes.

****************************
Le protocole CAN (Control Area Network) est un protocole de communication série qui supporte des systèmes temps réel avec un haut niveau de fiabilité. Ses domaines d&#8217;application s&#8217;étendent des réseaux moyens débits aux réseaux de multiplexages faibles coûts. Il est avant tout à classer dans la catégorie des réseaux de terrain utilisé dans l'industrie pour remplacer la boucle analogique 20mA.
La structure du protocole du bus CAN possède implicitement les principales propriétés suivantes :
- hiérarchisation des messages.
- garantie des temps de latence.
- souplesse de configuration.
- réception de multiples sources avec synchronisation temporelle.
- fonctionnement multimaître.
- détections et signalisations d&#8217;erreurs.
- retransmission automatique des messages altérés dès que le bus est de nouveau au repos.
- distinction d&#8217;erreurs : d&#8217;ordre temporaire ou de non-fonctionnalité permanente au niveau d&#8217;un n&#339;ud.
- déconnexion automatique des n&#339;uds défectueux.
*********************

Ajoute qu'on travaille en CAN avec de simples PICs à des vitesses de l'ordre de 1Mbits/s, et je ne vois pas que vouloir de plus pour l'application demandée.

Un conseil, étudie ce bus avant d'en dire du mal.

A+
Bigonoff


Numéro de l'article: 57169   |  De: Bigonoff   |  Date: 2003-11-12 19:12:01
   RE: Liaison série bi directionnelle
Desole, je connait bien le CAN et le protocole... Effectivement si tu laisse un transmetteur CAN SEUL, il va constament re transmettre, jusqu'a ce que tu branches un autre module, qui renvoi l'ACK( AR en francais) MEME si le paquet ne lui est pas destine. C'est sur NON RECEPTION de l'ACK qu'il retransmet et non sur une ERREUR de CRC du recepteur CIBLE. Au niveau CRC, la "double erreur" ou la triple ne s'annulent pas, c'est pas un checksum. Le CRC est tres fiable sur la detection d'erreurs (sans correction) meme avec une taille superieure a 8 octets. Oui,8 octets: uniquement pour passer des parametres (temperature, pression..).
Tu n'a pas compris le Pb des roues. Le CAN n'a pas ete prévu pour gerer des contre actions rapides, il peut partir (et des gens l'ont vu a leurs depends) en "vrille" sur l'ABS. Comme disent les motoristes: surchage du multiplexeur (le CAN). En fait c'est un probleme de reprise de collision sur des paquets de memes priorités!! (modules l'ABS). Et ca, c'est pas pardonnable sur un avion de chasse!.

Si nous pouvons communiquer c'est parque la transmission est bonne!!
Le RS485, est un niveau 0 (ISO): donc il faut effectivement mettre une couche X25 (niveau1) securisation des donnees(voir OM AX25).
En clair, c'est plus facile de placer le X25 sur le RS485 que sur le CAN, (ce qui a ete fait pour la remise a jour des calculateurs!!).
La taille fixe (8) est tres penalisant. Et l'ACK des qu'une station a recu le bon CRC (pas forcement celle qui dois recevoir le paquet) OBLIGE l'integralité de la couche X25!!.

Le CAN (Bosh oui)a ete concus par des motoristes, mon but est d'expliquer son domaine d'utilisation: MULTIPLEXAGE pour la mesure ou la consigne. Enfin le CAN a beucoup evolué. Je vais pas faire l'historique. Grosso modo au debut le multiplexage devait fonctionner tout seul, le calculateur s'occupe uniquement du moteur. Avec les problemes, resolue en ajoutant d'autres fonctions, une grosse couche logiciel a été ajoutee. La derniere: le X25 pour assurer la couche 1 de l'ISO, "integrite des donnes"... avec ca tu peux faire du web!!
XF





Numéro de l'article: 57214   |  De: XF   |  Date: 2003-11-12 22:22:59
   RE: Liaison série bi directionnelle
Salut
-----

Tu dis :

"Effectivement si tu laisse un transmetteur CAN SEUL, il va constament re transmettre, jusqu'a ce que tu branches un autre module, qui renvoi l'ACK( AR en francais) MEME si le paquet ne lui est pas destine. C'est sur NON RECEPTION de l'ACK qu'il retransmet et non sur une ERREUR de CRC du recepteur CIBLE."

Désolé, c'est faux. Si la trame est effectivement réémise en cas d'absence de cible, une trame d'erreur est automatiquement envoyée en cas d'erreur de réception de n'importe quelle carte connectée. La trame DOIT faire partie de la gestion hardware du fait de la norme, et doit provoquer le réenvoi du message. Donc, on est certain que le message est arrivé intact à toute carte connectée et en service (donc à la carte cible). De plus l'ack concerne l'intégralité des cartes connectées. Je cite :

*************
Le champ d&#8217;acquittement possède 2 bits. La station émettrice de la trame laisse le bus libre pendant 2 coups d&#8217;horloge (ce qui correspond à l&#8217;émission de deux bits récessifs) et elle passe en mode réception pendant le premier coup d&#8217;horloge.
Le premier bit correspond à l&#8217;acquittement par l&#8217;ensemble des n&#339;uds ayant reçu le message.
Si aucune erreur n&#8217;a été détectée par un n&#339;ud (après calcul du CRC), ce dernier émet un bit dominant sinon il émet une trame d&#8217;erreur. La station émettrice du message originel doit alors être capable de réagir en fonction de l&#8217;émission d&#8217;un bit dominant ou non par les autres stations sur le premier bit du champ d&#8217;acquittement.
Le second bit est un bit délimiteur d&#8217;acquittement qui doit toujours être récessif.
************

Tu dis :

Au niveau CRC, la "double erreur" ou la triple ne s'annulent pas, c'est pas un checksum. Le CRC est tres fiable sur la detection d'erreurs (sans correction) meme avec une taille superieure a 8 octets. Oui,8 octets: uniquement pour passer des parametres (temperature, pression..).

Je sais la différence entre un checksum et un CRC. En l'occurence, on peut aller jusque 5 erreurs. Je n'ai jamais nulle part dit que les erreurs doubles s'annulent. Par contre, au delà d'un certain nombre, on court le risque (faible, mais réel). Donc, comme j'ai dit, moins on a d'octets par trame, moins on a de risque, donc plus c'est fiable.
De plus, tu abondes encore dans mon sens, puisque le CRC est INTEGRE au CAN, et tu dis que le CAN n'est pas fiable.

Du reste, si tu veux la formule, la voici :
g(x)=x15+x14+x10+x8+x7+x4+x3+1.

En RS485, tu dois t'amuser à réaliser le polynôme par soft, en CAN c'est automatique.

Note que 8 octets par trame, ça ne veut pas dire 8 octets en tout. J'ai bien précisé que le bus était adapté à des échanges rapides et sécurisés de trames courtes. Où ai-je dit le contraire?

Par contre, ta vision du CAN est fort limitée, ça fait une paye que le CAN est utilisé dans un grand nombre d'applications, même s'il a été développé au départ pour le secteur de l'automobile.
Je répéte une dernière fois que la question de départ concernait l'échange d'informations entre mode multimaître entre cartes électroniques. LE 485 n'est pas adapté à un mode multimaître, parce que les collisions sont destructives.

Tu dis :
"Tu n'a pas compris le Pb des roues. Le CAN n'a pas ete prévu pour gerer des contre actions rapides, il peut partir (et des gens l'ont vu a leurs depends) en "vrille" sur l'ABS. Comme disent les motoristes: surchage du multiplexeur (le CAN). En fait c'est un probleme de reprise de collision sur des paquets de memes priorités!! (modules l'ABS). Et ca, c'est pas pardonnable sur un avion de chasse!. "

J'ai tout à fait compris. D'une part, où est-ce qu'on a parlé d'avions de chasse? D'autre part, chaque bus et chaque carte électronique a des limites physiques, et, si on les dépasse, on a des ennuis. Il suffit de faire l'étude correctement pour que ça n'arrive pas.

Des trames CAN n'ont JAMAIS la même priorité, sauf si elles sont strictement identiques. J'ai peine à croire qu'on arrive à surcharger un bus CAN en répétant tout le temps la même chose, en même temps, et à partir de plusieurs modules distincts, qui, par définition n'envoient pas les mêmes informations. Si c'était le cas, ce serait une erreur de programmation, pas un défaut du CAN.

Les motoristes, quand il y a un problème, c'est toujours la faute des autres, c'est connu. Maintenant, si un défaut CAN fait partir une voiture en vrille, il faut vite courir se plaindre chez Bosh et faire interdire le CAN. Le départ en vrille n'a JAMAIS été dû à une saturation du CAN, mais à des défauts intrinsèques à l'ABS (par exemple, il est pratiquement impossible de s'arrêter sur une neige dure avec un ABS). Les ABS mécaniques ou électroniques sans bus présentent STRICTEMENT le même problème. Ca n'a strictement rien à voir avec un avion de chasse, et ça ne démontre nullement l'inefficacité du CAN, c'est un problème de technologie ABS, parce que les paramètres sont difficiles à mettre en équation.

LE CAN, il travaille jusque 1 Mbits/s. C'est clair que si une application (avion, haut-débit internet etc) nécessite une vitesse de 100Mbits/s, il faut passer à autre-chose. Ca ne veut pas dire que le CAN n'est pas fiable, ça veut dire qu'il n'est pas prévu pour ces vitesses. Mais dans ce cas, le RS485 ne convient pas non plus. Or, encore une fois, la question initiale portait sur le choix judicieux ou pas d'une liaison RS485. L'utilisateur n'a pas demandé à piloter un avion de chasse.

Tu dis :

"Si nous pouvons communiquer c'est parque la transmission est bonne!! "

Ca, c'est clair. La-dessus, je suis d'accord, Lapalisse aussi.

Tu dis :
"Le RS485, est un niveau 0 (ISO): donc il faut effectivement mettre une couche X25 (niveau1) securisation des donnees(voir OM AX25).
En clair, c'est plus facile de placer le X25 sur le RS485 que sur le CAN, (ce qui a ete fait pour la remise a jour des calculateurs!!). "

Oui, ben tu essayeras de faire une liaison efficace et rapide en RS485 avec un système multi-maître.
Tu vas devoir passer un jeton ou établir un protocole, sans aucun maître pour gérer ça. Si une carte ne répond plus, tu vas devoir placer dans toutes les cartes des temporisations de sécurité, pour savoir quoi faire en cas de plantage d'une carte etc.
Ce n'est pas du tout, ni pratique, ni efficace. Je suis bien placé pour le savoir, j'ai réalisé un système domotique (entre autres) en RS485, et je suis en train de le recommencer en CAN, qui est beaucoup plus efficace, s'agissant de multi-maître.

Il n'y a nul besoin d'un protocole supplémentaire pour encapsuler les trames CAN, vu que CRC, ACK, informations complémentaires etc. sont DEJA intégrés dans les trames CAN. Ton protocole, il ne fait que refaire par software (en moins puissant) ce qui est fait par hardware dans le CAN.

Pour ce qui est de la confirmation de la bonne réception de la commande, il n'y a strictement RIEN qui empêche d'envoyer une réponse aux trames émises. C'est du reste ce que je fais sur une partie des commandes CAN de mon système domotique. Comme ça, mon logiciel de surveillance a une vue complète du réseau en temps réel. Une fois de plus, c'est plus simple à faire en CAN qu'en RS485.

Tu dis :
"La taille fixe (8) est tres penalisant. Et l'ACK des qu'une station a recu le bon CRC (pas forcement celle qui dois recevoir le paquet) OBLIGE l'integralité de la couche X25!!."

La taille n'est pas fixe, la taille est de maximum 8 octets de data, plus 29 bits d'ID. Ce n'est nullement pénalisant si on a conçu le système en conséquence, et, je le répéte, des trames courtes sont plus sécurisantes que des trames longues. Certes un peu moins rapides (pour le cas où on a un grand nombre d'infos à envoyer), mais plus sécurisantes, et même plus rapides pour peu qu'on ait des perturbations ECM sur la ligne (on a moins à réenvoyer).

On n'est obligé de rien du tout, tu as oublié les trames d'erreur en chemin. Si une carte reçoit un message erroné, elle renvoie AUTOMATIQUEMENT une trame d'erreur et le message est AUTOMATIQUEMENT renvoyé.

Le seul cas où on aurait un problème ignoré, c'est celui où la carte de destination ne serait plus raccordée au bus, et, si on veut s'assurer de ce cas particulier, il suffit que la carte cible renvoie une trame d'ACK. Tu es du reste obligé de faire ça sur du RS485, même pour le CRC (tu dois tout prendre en gestion par soft). Sur le CAN, ce n'est utile que si la carte ne répond plus. Or, si la carte ne
répond plus, à quoi sert de lui renvoyer l'information??? Le CAN n'a pas été pensé par des idiots, encore heureux.

Tu dis :

"Le CAN (Bosh oui)a ete concus par des motoristes, mon but est d'expliquer son domaine d'utilisation: MULTIPLEXAGE pour la mesure ou la consigne."

Ta vision est beaucoup trop limitative. Ce n'est pas parce qu'un bus a été conçu pour une application qu'il ne convient pas pour une autre.
Actuellement, le CAN est un des bus le plus en vogue dans les entreprises, or, j'ai rarement vu d'ABS sur un pont roulant.

Tu dis :

" Enfin le CAN a beucoup evolué. Je vais pas faire l'historique. Grosso modo au debut le multiplexage devait fonctionner tout seul, le calculateur s'occupe uniquement du moteur. Avec les problemes, resolue en ajoutant d'autres fonctions, une grosse couche logiciel a été ajoutee. La derniere: le X25 pour assurer la couche 1 de l'ISO, "integrite des donnes"... avec ca tu peux faire du web!! "

Heuu, pour info, non seulement ta conclusion te contredit : si on sait faire du web, on peut échanger des données entre cartes électroniques. Ensuite, la couche 1 de la norme OSI définit non pas l'intégrité des données, mais la couche physique, elle-même scindée en 3 sous-couches : (PLS Physical Signalling), PMA (Physical Medium Access), et MDI (Medium Dependent Interface).

Enfin, je ne parle pas d'un ancien hypothétique CAN initial limité, je parle du CAN actuel, le seul qui existe, et plus particulièrement de la version 2.0b.

Mais bon, on ne va pas passer 10 ans la-dessus. Mettons que chacun reste sur ses positions, et que personne n'est convaincu.

Celui qui veut se faire une idée par lui-même peut aller charger les docs chez Bosh, et peut aller télécharger sur mon site un bootloader CAN parfaitement opérationnel, et qui ne perd pas des octets, je le garantis.

A+
Bigonoff












Numéro de l'article: 57337   |  De: Bigonoff   |  Date: 2003-11-13 20:53:30
   RE: Liaison série bi directionnelle
Bonjour,mon but n'est pas de dire qui est le mieux, mais leurs utilisations. Le CAN pour le multiplexage donne/consigne en multimaitre avec des circuits complexe et "couteux" puisqu'il integre toute la gestion CAN. Dans une usine le CAN est pour la lecture des capteurs, la consigne au machine OK, mais luxe. Faire passer un message, non, il manque la couche X25.. Le RS485 est non multimaitre effectivement, l'USB aussi et le nouveau bus LIN et le bus avion c'est pas une tare, ca marche aussi oui tous ces bus recoivent un jeton. On place du multimaitre quand les stations ont la meme importances, ex des PCs (INTERNET 10/100Mbits/s). En RS485 le bus DMX (pour le controle des lumieres de spectacles) fonctionne,(il est vrai il est "rudimentaire"). Des lors qu'il y a un maitre (un calculateur, ou deux par redondance), des capteurs ou des actionneurs (esclaves) le mode mutimaitre n'est pas necessaire. C'est pour cela que les nouveaux bus ne l'ont pas . Enfin, en charge un syteme a collision de paquet, le bus peut "tomber" (un court instant dit temps de reprise) CAN /INTERNET pour eviter cela: deux bus CAN moteur/ABS!.
Le time slot (GMS/ AVION)rudimentaire mais le plus efficace consomme.
Les constructeurs automobile calcul les temps sur une chaine (le temps c'est de l'argent), si il avait trouver une methode plus simple (en utlisant les avantages du CAN) pour eviter de placer une couche X25, avec le temps induit, il l'aurait fait...En clair c'est plus long que le temps de programmation d'un octet de memoire flash ( et on aurait aime le contraire).
XF



Numéro de l'article: 57352   |  De: XF   |  Date: 2003-11-13 23:25:16
   RE: Liaison série bi directionnelle
Ci joint la norme "X25", l'introduction (en anglais).
Prevu a l'origine pour le diagnostic (envoie d'ordre, message, dump..)
Elle permet d'installer le network layer protocol.
Par contre, mea culpa on peut passer 4/6 octes par paquet ( et pas deux) comme je l'avais dit (de memoire).

ISO 15765 has been established in order to define common requirements for vehicle diagnostic systems implemented on a Controller Area Network (CAN) communication link as specified in ISO 11898 Road vehicles - Controller area network (CAN).
Although primarily intended for diagnostic systems, ISO 15765 has been developed to also meet requirements from other CAN based systems needing a network layer protocol.
To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model in accordance with ISO/IEC 7498 and ISO/IEC 10731 which structures communication systems into seven layers.
XF


Numéro de l'article: 57359   |  De: XF   |  Date: 2003-11-14 00:29:50
   RE: Liaison série bi directionnelle
On va bien voir, de toute façon, j'ai assez peu de temps pour mettre en oeuvre un système de controle des accès en service dans l'atelier.

Je vais me renseigner chez Bosch pour les protocoles et les différentes couches. Peu importe le protocole uilisé pourvu que ca fonctionne et que ce soit facilement implémentable dans un µC.

Le fait que le CAN possède des drivers tout prêts est séduisant car le RS485 ne possède pas de protocole défini donc les seuls drivers (que je connaisse en tout les cas) se limitent à convertir du 0-5V en signal symétrique.

Merci à tous les deux
Frédéric

Numéro de l'article: 57372   |  De: frederic   |  Date: 2003-11-14 09:06:15
   RE: Liaison série bi directionnelle
De memoire je savais qu'une couche X25 ISO 15765 etait necessaire a cause de la perte de paquet en CAN, ( et pour cause j'ai ete dessus) j'ai effectivement fait une erreur sur le motif.

Pourquoi l'ISO 15765?.
A cause du principe du CAN: il donne toujours la derniere mesure/consigne , il ecrase donc le paquet precedent (d'ou la perte au sens reseau), pas de buffer. Aussi la norme ISO15765 met en place une negociation pour savoir a qu'elle rythme envoyer les paquets
pour que le calculateur ait le temps de le recuperer avant qu'il soit ecrasé par le suivant. Ce rythme depend uniquement du programme, ce n'est donc pas le debit du CAN qui fixe le debit reel mais
la caracteristique du soft. SeparationTimeMin (STmin): The minimum time the sender shall wait between the transmissions of two
ConsecutiveFrame N_PDUs. Puis la norme reprend le X25 a savoir reprise en cas de perte... Les controleurs internet en hard reassemble les paquets d'ou le debit effectif de 10/100Mbits/s (et gere la couche X25 ou equ en hard) (collision multimaitre comme le can). En CAN, les motoristes veulent des controlleurs multifiltres pour le "maitre": le calculateur ou le PC..
(Intel, Siemens..) ainsi (1Filtre=1 canal=1mesure) ils ont en permanence (15) mesures en memoire, le calculateur s'occupe uniquement du moteur. Le chip Philips non multifiltre oblige le calculateur (host) a faire le tri en permanence. Le chip Philips est OK sur les capteurs, il envoi "tranquille" periodiquement la valeur mesuree. En mode CAN/Reseau on peut conserver avec les multifiltres par exemple 14 CAN, transparent et un avec action rapide pour recuperer les paquets reseaux (STMin faible).
Quand mettre l'ISO 15765?
Quand on veut envoyer un message de plus de 8 caracteres...(un numero de telephone!!).
En ISO niveau 7: Application CONTROL (mesure/consigne) la norme CAN
En ISO niveua 7: Application reseau (transfer de donne) CAN + ISO15657
Quand on recharge un programme pour un calculateur de bord on en peut pas se permettre d'oublier un morceau. Desole pour les imperfections de ma memoire, mais ca fait deja pas mal de temps que je fait plus de CAN. Mon objectif: donner des informations les plus precises.
Il est capital de savoir ce qu'on peut faire, et dois faire avant d'installer un reseau!!. Au niveau soft "ouvert" GNU, le CAN est pauvre, les fabricants d'auto sont pas GNU!. Pour les reseaux domotique maitre, c'est plus ouvert en RS485 (USA tres utilise). Pour les reseux mutimaitres, c'est internet (voir le prix d'une carte reseau), ce serait mon choix pour une nouvelle etude y a du GNU qui pointe.

XF

Numéro de l'article: 57396   |  De: XF   |  Date: 2003-11-14 13:50:19
   RE: Liaison série bi directionnelle
Salut
-----

Arf.

Tu dis :

"Le CAN pour le multiplexage donne/consigne en multimaitre avec des circuits complexe et "couteux" puisqu'il integre toute la gestion CAN. "

Un pic, c'est coûteux? LOL. C'est exactement le même prix pour une liaison CAN avec un pic (PIC + MCP2551) que pour une liaison RS485 (PIC + MAX485)

"Faire passer un message, non, il manque la couche X25.."

LOL. On ne peut pas faire passer un message en CAN, première grande nouvelle. Je te le répéte, va voir sur mon site, LOL.
Et en RS485, on peut sans doute? LOL. Le 485, il ne précise rien, on doit tout gérer par soft, on se contente d'envoyer des octets (bonjour le temps CPU consommé).

" Le RS485 est non multimaitre effectivement, l'USB aussi et le nouveau bus LIN et le bus avion c'est pas une tare"

Ben si, et une énorme en plus en fonction de l'application. Ca peut n'avoir aucune importante, mais ça peut aussi en avoir une énorme.

Et je te rappelle l'énoncé de la question de départ :

"Je souhaite mettre en oeuvre une liaison série bi directionnelle en RS485. Le but est de faire dialoguer plusieurs cartes électroniques en mode multi-maître. "

Ca me semble clair. Donc, comme je dis depuis le début, le 485 ne CONVIENT PAS. Le CAN OUI. Dur dur.

Tu n'as qu'à essayer de réaliser mon système domotique décentralisé avec ton RS485, pour rire un coup.

"ca marche aussi oui tous ces bus recoivent un jeton. On place du multimaitre quand les stations ont la meme importances, ex des PCs (INTERNET 10/100Mbits/s). "

Le jeton, c'est un pis-aller. C'est fortement dérangeant car chacun doit savoir qui va prendre la parole après. Et si on passe la parole à quelqu'un qui n'a rien à dire, il doit répondre "je n'ai rien à dire". En cas de perturbation du réseau, il faut savoir à qui revient le jeton, et que faire si celui à qui revient le jeton ne répond pas suite au plantage du réseau, etc. En cas d'un plantage quelconque, on risque que deux stations aient le jeton en même temps, etc.

C'est pénible si on veut que tout le monde puisse prendre la parole uniquement lorsqu'il a quelque chose à dire.
Le multi-maitre, ce n'est nullement quand toutes les stations ont la même importance, l'I²C fonctionne en multimaître même si les périphériques ont des rôles différents. L'avantage du multimaître, c'est qu'on peut parler sans attendre d'avoir le droit à la parole, et qu'il n'y a besoin de personne pour gérer la communication.
X peut parler à Y pendant que U parle à V, sans problème.
Mettre ça en place avec un RS485, c'est un challenge.

"En RS485 le bus DMX (pour le controle des lumieres de spectacles) fonctionne,(il est vrai il est "rudimentaire")"

Ce n'est pas du tout la même application. On a un pilote et des esclaves, donc pas de multimaître. Je n'ai pas dit que le RS485 n'était pas un bon bus (je viens encore de le mettre en application dans un appel infirmière sophistiqué pour une maison de repos, avec une centrale, donc un maître) j'ai dit qu'il ne convenait pas à l'objectif initial, c'est à dire multimaître (ou sans maître, ce qui revient au même).

"Des lors qu'il y a un maitre (un calculateur, ou deux par redondance), des capteurs ou des actionneurs (esclaves) le mode mutimaitre n'est pas necessaire"

Ben, C'est encore une lapalissade. Justement, le problème se pose quand il n'y a pas de maître, et c'est le cas de la question d'origine. L'internaute n'a pas demandé "le multimaître m'est-il nécessaire? Mais : "comment mettre en oeuvre une liaison multimaître?".

Répondre à l'intérêt ou pas du multimaître équivaut à connaître l'application, et on ne la connait pas.

"C'est pour cela que les nouveaux bus ne l'ont pas "

Ca ne veut strictement rien dire. Un bus est prévu pour gérer ou pas les collisions, le multimaître ou pas. Ca dépend du cahier des charges prévu lors de sa création, ça n'a strictement rien à voir avec une quelconque mode ou un problème de date de création.

"Les constructeurs automobile calcul les temps sur une chaine (le temps c'est de l'argent), si il avait trouver une methode plus simple (en utlisant les avantages du CAN) pour eviter de placer une couche X25, avec le temps induit, il l'aurait fait...En clair c'est plus long que le temps de programmation d'un octet de memoire flash ( et on aurait aime le contraire). "

Ecoute, cette fois-ci, tu dis vraiment n'importe quoi. Une dernière fois, va sur mon site, et teste le bootloader CAN. TU verras si c'est la programmation flash qui attend le CAN ou le contraire. Je pilote des messages de tout type avec des trames CAN, et ce, sans aucun problème. UNe trame CAN se suffit à elle-même. Rien n'empêche d'ajouter des protocoles softwares, du reste, il faut bien établir les règles pour les ID, mais rien qu'avec l'envoi et la réception de trames, on fait ce qu'on veut.

Les contructeurs automobiles, ils ont ajouté une couche dans leurs microcontrôleurs, qui leur permet de développer des applications indépendantes du microcontrôleur sur lesquels ils tournent. C'est un noyau multitâche, les procédures sont chargées sous forme de tâches. Les trames répondent aussi à une structure particulière, ce qui explique les protocoles mis en place. Tout ça est fait uniquement pour limiter les coûts de production, et pour que le logiciel développé par X puisse être utilisé par le fabricant de cartes Y pour être montés sur une voiture Z. Bref, ça leur permet d'échanger les logiciels pour éviter les frais de développement. On ne parle pas de ça ici.

Quand à ta référence, il est clair, et je n'ai jamais dit le contraire, qu'on peut utiliser des octets de data (en l'occurance 2) pour établir des informations complémentaires, dans le but de libérer un maximum d'ID possible, et donc d'élargir le champ d'application.
Cependant, ce n'est NULLEMENT indispensable. Mes applications ont à disposition les 8 octets de data pour l'usage interne, et le système est parfaitement sécurisé.

Si je décide d'ajouter une couche qui précise que D0 et D1 représentent, par exemple, un numéro de réseau, ou un numéro de trame, alors je perds 2 octets, MAIS ça dépend de l'application envisagée et ce n'est NULLEMENT une obligation. Si je fais pareil avec un autre bus, il faut bien que j'ajoute des infos également (c'est ce qui se fait dans le TCPIP). Ca ne ralentit pas plus sur le CAN que sur un autre bus. Simplement, vu que le CAN limite le nombre d'octets à 8, je décomptes 2 octets sur les 8 possibles au lieu d'ajouter 2 au nombre initial. On obtient des trames plus courtes en CAN, mais plus sécurisées, soit le contraire de ce que tu dis.

"De memoire je savais qu'une couche X25 ISO 15765 etait necessaire a cause de la perte de paquet en CAN"

Tu t'obstines, mais il n'y a PAS de pertes de trames en CAN, SAUF si le système est mal conçu. Le RS485 ne dispose d'AUCUN moyen de vérification d'intégrité hardware, et est donc plus fragile que le CAN

A-t-on jamais vu quelqu'un qui propose un bus qui perd des informations? Je t'ai démontré qu'il y avait des mécanismes, et lesquels. Toi, tu te bornes à répondre "le CAN perd des trames".
La discussion n'est pas constructive, tu n'a répondu à aucune argumentation technique.

"A cause du principe du CAN: il donne toujours la derniere mesure/consigne , il ecrase donc le paquet precedent (d'ou la perte au sens reseau), pas de buffer. "

ARGGG. !!!

AUCUN (NOTHING) message n'est écrasé en CAN. Les trames sont reçues dans un des buffers de réception (si si, des buffers) du micro de gestion CAN, et APRES masquage et filtrage. Partant de là, tout soft bien fait vide le buffer par interruption, et sauve le message pour traitement ultérieur si besoin est.

Durant ce temps, la trame suivante arrive dans le buffer de comparaison, pour y être exposée aux masques et filtres avant rangement dans les buffers de réception, S'ils sont vides. Le logiciel a donc largement le temps de vider le buffer de réception (et il y en a souvent plusieurs) avant l'arrivée du message suivant.

De toutes façons, le message ne sera jamais écrasé, tu auras dans le pire des cas (si tu ne traites pas les messages entrant) un message de type "overflow". Car, c'est clair que, et pour n'importe quel bus, si tu ne vides pas tes buffers d'entrée, tu vas finir par ne plus pouvoir recevoir. Essaye en RS485 pour rire un coup.

Et encore, en RS485, avec un micro, tu es obligé de vider octet par octet, tu es obligé de lire TOUTES les trames, même celles qui ne te concernent pas.

Par contre, en CAN, tu ne vide que trame par trame (donc on a beaucoup plus de temps), et, en plus, on ne reçoit que les trames qui sont destinées à la carte (donc on consomme de 10 à 1000 fois moins de temps CPU en fonction de l'application).

Franchement, ce que tu dis là démontre que tu as lu des infos sur le CAN, mais que tu les a mal comprises, et probablement jamais mises en application dans un microcontrôleur. Il ne faut pas confondre les limites du CAN avec les limites de certains contrôleurs CAN désuets d'il y a quelques années.

De même, si j'utilise un PIC à 1Mhz pour traiter des trames RS485 à 1Mbits/s, je ne vais jamais y arriver.

"Intel, Siemens..) ainsi (1Filtre=1 canal=1mesure) ils ont en permanence (15) mesures en memoire, "

Un 18F248 : 6 filtres et 2 masques. Faut évoluer. En interne, 3 buffers de réception hardware, et 2 fois 256 octets de buffer en soft.

"Quand mettre l'ISO 15765?
Quand on veut envoyer un message de plus de 8 caracteres...(un numero de telephone!!). "

Tssss. Je fais un bootload d'un programme de 32Koctets avec des trames CAN, sans utiliser de protocole spécifique autre qu'un simple échange de trames CAN.
Ce que tu dis n'a aucun sens.
Je répéte encore une fois : 8 octets de data par trame, ça ne veut pas dire 8 octets en tout. Tu peux gérer les data comme bon te semble. Evidemment, il te faut des conventions, ou un protocole de ton choix, MAIS c'est pareil avec tout échange de données, que ce soit RS485 ou TCPIP, par exemple. Ce n'est nullement une limitation du CAN, simplement un choix entre trames courtes et trames longues.

"Quand on recharge un programme pour un calculateur de bord on en peut pas se permettre d'oublier un morceau"

On n'OUBLIE RIEN EN CAN, pas plus qu'avec un autre réseau si le réseau est correctement mis en oeuvre. Si on perd quelque chose, ce n'est pas la faute du réseau, c'est la faute de sa mauvaise mise en oeuvre, ou d'une mise en oeuvre inadaptée au fonctionnement requis.

Tu crois que je peux me permettre d'oublier un morceau quand je recharge un PIC? LOL. Et mon application domotique n'est pas la seule où j'utilise un bootloader CAN, j'ai aussi une grosse application commerciale, avec upgrade par le client en CAN, carte en service.

C'est comme si je disais : en RS485, on perd des informations, parce que mon contrôleur n'arrive pas à tout lire à cause qu'il n'a pas le temps de vider son buffer. C'est insensé de dire ça.

"Desole pour les imperfections de ma memoire, mais ca fait deja pas mal de temps que je fait plus de CAN. "

Ben, j'avais cru comprendre, oui. Tu confonds sans doute les limitations du CAN avec les limitations des anciens périphériques de contrôle obsolètes.

"Il est capital de savoir ce qu'on peut faire, et dois faire avant d'installer un reseau!!. "

AHHHHHHHHHHH, enfin.
Donc, je te rappelle que l'utilisateur VOULAIT un réseau multimaître.
Et le CAN est le plus adapté dans ce cas.

"Au niveau soft "ouvert" GNU, le CAN est pauvre, les fabricants d'auto sont pas GNU!."

Qu'est-ce que ça a à voir? Qui veut construire un ordinateur de bord pour automobile???

Le CAN est beaucoup moins pauvre que tu ne penses, cherche mieux sur le net.

"Pour les reseaux domotique maitre, c'est plus ouvert en RS485"

Effectivement, MAIS on ne veut pas du maître !!!! On a dit "multimaître". Si l'utilisateur avait parlé d'une centrale qui pilote des cartes esclaves, je lui aurait dit "RS485", parce que c'est plus simple à comprendre.

J'ai fait une installation domotique RS485 en maître, ce n'est pas pratique. Une panne du maître et plus rien ne va dans la maison.
En plus, on passe son temps à interroger les cartes, ou on doit ajouter des fils de requête de parole. Pas pratique.

Avec mon système, une panne = panne de la fonction, le reste tourne toujours, c'est beaucoup plus flexible. Pas d'événement = aucun trafic sur le bus, c'est plus économique.

"Pour les reseux mutimaitres, c'est internet (voir le prix d'une carte reseau)"

Ben, tu essayeras de connecter ta carte réseau sur un microcontrôleur.
A moins que tu ne veuilles faire un système domotique avec un PC par fonction? LOL. Je te rappelle qu'on parle d'échange d'informations entre cartes électroniques, et non entre PC.

"ce serait mon choix pour une nouvelle etude y a du GNU qui pointe."

Moi, ce n'est pas mon choix, et ce n'est pas "serait", c'est "c'est".
Et tout sera disponible gratuitement sur mon site, avec les sources. C'est peut-être pas officiel "gnu", mais pour l'utilisateur, c'est tout comme.

Et des sites qui proposent des réalisations CAN gratuites, il y en a d'autres, je ne suis pas le seul.

Des systèmes domotiques décentralisés à base de carte "réseau internet", j'ai pas trouvé, même en GNU, désolé

A+
Bigonoff



















Numéro de l'article: 57462   |  De: Bigonoff   |  Date: 2003-11-14 20:29:55
   RE: Liaison série bi directionnelle
Bonjour,
Evidement que l'on peut faire des choses qui "fonctionnent", mais quand il sagit de passer a une normalisation (ISO), puis sur un banc de test (de stress), la couche est complexe, et les performances s'en ressentent. Oui, sur table on charge vite une flash, mettre la couche X25 n'a pas ete une partie de plaisir. On est d'accord, le temps de latence d'IT definit le taux de transfert max. Dans un systeme "heterogene" (en CAN et autres) il faut un preambule de negociation... Des protocoles sur les coins de tables, j'en ai vu, j'en ai fait aussi, et j'ai vu des degats, donc depuis longtemps j'ai compris qu'il faut, meme si c'est lourd UTILISER les ALGORITHMES des couches ISO. (meme les OM l'on compris avec l'AX25) Cette normalisation n'est pas facile a mettre en oeuvre, souvent c'est en equipe de programmeur. Effectivement la question etait "multimaitre avec RS485", c'etait pas possible electriquement, le debat ici est ouvert, la reponse est "avant le choix de l'implementations il faut definir un cahier des charges." Le CAN, le RS485 LIN ... ont leurs avantages et leurs inconvenients, un conseil, en pro, la solution passe par l'ISO.
A+
XF





Numéro de l'article: 57493   |  De: XF   |  Date: 2003-11-14 22:42:47
   RE: Liaison série bi directionnelle
Salut
-----

Respecter l'ISO, ça ne veut strictement rien dire.

La norme CAN définit 2 couches ISO, les autres sont au choix de l'utilisateur.

Une fois que tu établis un protocole, même comme tu dis "sur un coin de table", on crée une couche ISO.

Respecter une couche ISO particulière est utile si et seulement si on désire une compatibilité avec un autre système utilisant les même contraintes sur la même couche. Dans le cas contraire, ça ne signifie strictement rien. Pourquoi devrais-je respecter une couche ISO définie pour les échanges sur les bus automobiles si mon désir est d'interfacer mon CAN avec internet, ou avec un système déjà existant? Ca n'a aucun sens.

Dire "en pro, la solution passe par l'ISO" ne veut strictement rien dire du tout. ISO quoi? quelles couches? Quel protocole? Pourquoi faire?

Si par "pro", tu entends un type qui développe des applications commerciales, alors je suis un "pro", et mes systèmes fonctionnent parfaitement. Je ne respecte une norme particulière d'une couche ISO que si j'en ai l'utilité, par exemple si je veux m'interfacer sur un bus existant, ou si je veux être compatible avec une application particulière. Dans le cas contraire, je respecte les couches ISO imposées par le type de bus que j'utilise (2 couches en l'occurance pour le CAN), et le reste, j'utilise à ma meilleure convenance.
Il n'y a pas de couche ISO qui contienne un seul et unique mode de fonctionnement. On ne peut pas dire : "je suis compatible ISO", c'est une abbération.

Passer au banc de stress, c'est principalement vérifier les problèmes de CEM (90%), et vérifier qu'on a bien mis en oeuvre le bus (10%).

Il n'y a PAS d'algorythme ISO à appliquer dans tous les cas, tu mélanges tout. Il y a des contraintes de certaines couches en fonction de certains systèmes, il n'y a rien d'universel.
Les définitions des couches sont complètement différentes pour le CAN que pour le TCPIP. Certaines couches dans certains systèmes sont ouvertes, pour permettre justement d'interconnecter, par exemple, une couche physique de son choix sur un protocole de transmission déterminé.

Franchement, j'ai l'impression que tu mélanges un peu tout.
C'est mon avi

A+
Bigonoff


Numéro de l'article: 57612   |  De: Bigonoff   |  Date: 2003-11-15 18:59:41
   RE: Liaison série bi directionnelle
Bonjour,
L'ISO sert a permettre une interoperabilite, quant on veut s'ouvrir vers l'exterieure, pas seulement dans son coin. L'automobile, demmandes des fonctions, l'industrie aussi, l'ISO donne des fonctions, reprend ce qui existe quand elle constate que cela repond a la fonction. Ex: le port centronic, fonction: impression... IEE488: mesure avec ce bus. Pour le CAN c'est mesure/controle, puis transmission de donne. Oui, l'automobile a ete (et est) un precurseur dans la normalisation (enjeu economique). Bosh c'est l'auto. Pour le diag on CAN (auto) fonction transmission de data, effectivment les circuits CAN (ex microchip) on evoluee, deux modes: CAN ou buffer (pour l'X25 le diag on CAN, la fenetre plus grande, l'IT plus souple...) En utilisant l'ISO 15765 on peux "melanger" les vieux contoleurs, les actuels et les futurs.. c'est aussi ca une norme. En "pro" pour les industriels (eviter le veto d'une propal) toutes les solutions doivent etre basée sur des fonctions "ISO", quand elles existent. Pour les autres fonction un dossier "solide". Proposer "sa solution fonction" en remplacement d'une de l'ISO?, veto: interoperabilite sans aller plus loin. L'ISO c'est surtout un algorithme QUI MARCHE et permet de savoir rapidement ce qu'il faudra POUR realiser la FONCTION (code, taille). Meme l'algo du jeton n'est pas evident. C'est pas Pasteur qui a invente les microbes, ni la CEM, en 1985 sur un reseau internet (pro DEC) tranceiver dans les faux plafonds, on detectait l'allumage des neons ou certain neon HS (starter) en monitorant les reprises, au niveau transfert de datas pas de pbs.
Un stress type: un groupe A de modules CAN avec l'emetteur du paquet, bien plus loin un groupe B. A et B doivent recevoir l'info de l'emetteur. Au moment du paquet, parasite sur B (maximum), perturbe pas A. L'emetteur saura t il que B n'a rien recu ?.
OUI c'est du CEM, mais aussi verifier que le systeme retombe sur ces pieds.. les fonctions (cas CAN et cas Transfert de data) seront elles assurées?. Le plus grave c'est quand on voit rien, une cloture de session c'est moins grave: au moins on sait a quoi s'en tenir....
L'ISO donne la fonction: presentation, routage (couche)... meme printer (fonction), l'algo (enchainement, automate), pas l'implementation. Je prefere mettre un petit ISO simple, JETON maitre/esclave, un petit PIC 628, a 19K2 (domotique) (genre Domosysteme, un vieux fabricant "domotique") plutot que mi rapide non ISO. De toute facons en ce moment, quand on passe un cable dans une maison, c'est un coax!! (quand pas un 100mbit avec routeur) , pour relier les PC de la maison... et plus quand ca existera (domotique).
A+
XF


Numéro de l'article: 57657   |  De: XF   |  Date: 2003-11-16 00:43:56
   RE: Liaison série bi directionnelle
Salut
-----

>"L'ISO sert a permettre une interoperabilite, quant on veut s'ouvrir vers l'exterieure, pas seulement dans son coin. "

L'ISO détermine les couches, et, au sein de chaque couche, on peut avoir toutes sortes de protocoles.
On utilise les protocoles correspondants quand on veut s'interconnecter avec un système déterminé. Sans quoi, ça n'a aucun sens. Du reste, il est impossible d'être compatible avec tout, et donc il faut choisir en fonction de l'application. Ce que tu appelles "l'interopérabilité" est utopique. Tu ne peux être compatible qu'avec un système précis, et pas avec tout.

>"Pour le CAN c'est mesure/controle, puis transmission de donne"

Je t'ai déjà indiqué que ta vision du CAN est beaucoup trop limitative. Pourquoi veux-tu qu'une application domotique, par exemple, utilise des protocoles de communication propres à l'automobile???? Ca n'a pas de sens.

>"Un stress type: un groupe A de modules CAN avec l'emetteur du paquet, bien plus loin un groupe B. A et B doivent recevoir l'info de l'emetteur. Au moment du paquet, parasite sur B (maximum), perturbe pas A. L'emetteur saura t il que B n'a rien recu ?. "

Oui, parce qu'il est impossible que B ne reçoive rien du tout. Si parasite (parlons plutôt de perturbations CEM) il y a, alors le message arrivera erroné, et une trame d'erreur sera envoyée AUTOMATIQUEMENT par A. Pour que rien n'arrive sur A, il faudrait que le bus reste calé durant toute la transmission sur un niveau récessif. Or, une perturbation ECM, ce n'est pas une tension continue.

De plus, et je te l'ai déjà indiqué, rien n'empêche pour une application spécifique, d'envoyer explicitement un accusé de réception (ce que tu es de toutes façons obligé de faire en RS485)

>"OUI c'est du CEM, mais aussi verifier que le systeme retombe sur ces pieds.. les fonctions (cas CAN et cas Transfert de data) seront elles assurées?. "

Oui, elles le sont. Etudie la norme CAN, c'est justement son point fort.

>"un petit PIC 628, a 19K2 (domotique) (genre Domosysteme, un vieux fabricant "domotique") plutot que mi rapide non ISO. "

Sorry, mais moi je travaille à 500Kbits/s, et j'ai des applications commerciales qui tournent à 100Kbits/s sans aucun problème.

"non ISO", je t'ai déjà dit que ça ne veut strictement rien dire.
ISO détermine 7 couches de communication, elle ne détermine pas le cahier des charges des 7 couches de façon générale, mais pour chaque cas particulier. La couche x ISO pour le TCPIP n'est pas la même que pour le CAN, par exemple. Quand tu crées une couche, même de ton invention, tu crées automatiquement une couche ISO. Tu ne peux donc pas communiquer si tu n'utilises pas de couche ISO, même sans t'en rendre compte.

J'utilise un bus CAN, donc je respecte les couches ISO imposées pour le bus CAN, soit 2 couches. Les autres, c'est à moi de les créer. Je suis donc compatible avec tout périphérique CAN. Pour être compatible avec un système déterminé travaillant en CAN, je dois adopter les autres couches du dit système.

Si je voulais être compatible avec, par exemple, une automobile, j'utiliserais les protocoles utilisés par l'automobile pour les autres couches. Seulement, ce n'est pas le cas, alors la compatibilité avec l'automobile ne m'intéresse pas.

Du reste, tu parles de domotique : les systèmes domotiques actuels ne sont compatibles avec rien du tout, même pas avec les autres systèmes domotiques. Les gens qui ont développé ces applications ont pourtant utilisé les couches ISO.

Du reste, je serais alors incompatible avec les protocoles utilisés pour d'autres communications. Donc, de toutes façons, je ne serais jamais compatible avec tout ce qui existe, il faut choisir.

En plus, ton système jeton maître/esclave, ça ne MARCHE PAS dans une application sans maître, comme la mienne. Or, pourquoi lorsque mon interrupteur allume la lampe du salon dois-je passer par une unité centrale, qui renverra l'info? Ce n'est pas rentable, ni en terme de fiabilité ni en terme de vitesse (2 fois plus de trames), et en plus ça fragilise le système (panne de l'unité centrale = plus d'installation électrique dans la maison). Donc, tu essayes depuis le début de me dire qu'un protocole sous RS485 est meilleur qu'en CAN, alors que pour l'application donnée, ça ne fonctionne tout simplement pas.

J'ai DEJA (je l'ai déjà dit) fait un système domotique à base d'un maître sur un réseau RS485, et c'est moins pratique que le nouveau système que je suis en train de concevoir, à base de CAN décentralisé. Je suis bien placé pour le savoir, puisque j'ai fait les deux.

Par contre, j'ai fait (par exemple) un système d'appels infirmières relativement performant en RS485, et ce sans aucun problème, tout simplement parce qu'il y a une centrale dans ce genre d'application, donc un maître.

Faut comparer des poires avec des poires, et des pommes avec des pommes.

A+
Bigonoff






Numéro de l'article: 57791   |  De: Bigonoff   |  Date: 2003-11-17 00:15:56
   RE: Liaison série bi directionnelle


Bonjour,
L'ISO XXX c'est une GARANTIE: on evite les erreurs d'un fait main, sur table. Le plus "publicitaire" ISO9000: garantie QUALITEE. On n'est pas ISO quand on fait "sa fonction" (sa couche selonl'ISO), mais quand on utilise l'algo (les regles) de la fonction decrite par ISOXXXX. Le pire: ISO9000: 5 pages 20 chapitres... donne des kilos de papier en codage, c'est pas de l'informatique. Le stress ici, les certificateurs qui epluchent puis le tampon ( et la remonte si on l'a pas). En tete des documents ISOXXXX "pour realiser la fonction..." Le CAN repond au besoin d'une fonction: le multiplexage, pour reduire les fils, c'est tout. Oui,par Bosh, c'est l'auto la premiere utilisatrice. L'industrie a suivie pour la meme raison: multiplexage des mesures et commandes. L'ISO ici c'est seulement ca (ni huile, ni compte tours! ca c'est ultra top secret) . Les fonctions "Multiplexage" et "transmission data" sur CAN sont decrites dans les ISOXXXs. ya rien a "inventer", seulement coder. Au dessus ISO (7): oui la domotique (la je sais pas), je pense que chaque fabricant essaie ISOfier son standard (garantie), pas compatible oui!!....
Ce multiplexage (CAN) devait etre transparent pour les CPU des modules (calculateurs...)(pas de soft):c'est la raison du "multimaitre" dans le CAN. En realite, il a fallu mettre du soft (ex datation des messages). Un parasite peut empecher la reception, oui mais le module CAN va tuer la trame?. Et si UN module recoit mal (KO), il bloque tous le reseau (dur dans la voiture ou la maison) car il doit tuer TOUTES les trames... Alors on choisit de pas faire tuer les trames... .
Des compteurs d'erreurs (de perte de trames) sont INTEGRES dans les chips (pour surveiller le taux d'erreurs et auto rideau du module (OFF) (surtout si il est actif en erreur, donc flingueur). Le CAN assure uniquement que les donnes d'un paquet sont correctes, en domotique: mesure de temperature, on off...
Le CAN n'assure pas qu'apres le paquet 1 on a le paquet 2. L'auto (encore) ayant besoin de cela pour la foncion transmission de data a a joute le "diag on CAN". Remmetre a jour un programme n'est pas qu'automobile. Passer un descripteur, charger une table d'horaire etc..?.

L'auto "ISOfie" pour reduire les couts, l'interoperabilité des EQUIPEMENTIERS, (du CAN dans les casses ca c'est tres positif!!). Le modele ISO: un tube a 7 couches, une application demandant du multiplexage aura le tube CAN (avec les deux couches can/hard, et des niveaux vides....) Une application demandant le transferts data aura la couche ISO15657 + les couches CAN. Oui, on peut en mettre une autre, mais c'est la plus simple, prevu pour le CAN, pour la fonction DATA. La fonction multiplexage est un "petit reseau", la fonction "web" un tres gros, un tube TCP/IP a des paquets plus gros que le CAN et son CRC. Pour la meme fonction il y aura deux calculs du CRC. Le CAN decoupera le paquet web!!(calcul CRC), le donne "reconstitue? pas garantie", re CRC par le web. L'ISO15657 est fait pour le CAN et il tiens compte du deja present (CRC).En clair: integrite du paquet: CAN. Continuite paquet, negociation debit/ fenetre ISO15657.

Le CAN (comme tous les reseaux RS485..) son encadrés: soit par l'humain dans la voiture (contact), soit par l'employe (coup de poing), surveillance d'usine, soit par des systemes redondants. Le bus est "sensible" on a interet a segmenter (moins couteux que la redondance) l'auto (encore: oui adore le platre!!...) d'ou deux bus CAN, du LIN etc. L'auto pour "le test du feu" c'est pas mal, evidement il ne communique pas les "gros plantages", mais forcer un double CAN avec le cout en plus....!!.

Au niveau debit ma souris RS232 sur PC suffit, alors pour un interupteur 500Kbit/s en domotique?.

Les anti vol decoupent la maison en zone. Des maitres gerant une zone (piece), independant avec une RS485 local ou LIN. Le maitre a un opto-isole RS485 vers le central (Tandem). Le LIN: autobaud: sans quartz (derive 14%) uart soft!!, le master envoie un header a slave1, reponse pour slave 2!! interupteur< >lampe!! enfin notion de sommeil: reduction energie. LIN: pas ISO, en voie, pas stable LIN2.0.. "LIN (Local Interconnect Network) is a concept for low cost automotive networks, which complements the existing portfolio of automotive __multiplex__ networks. LIN will be the enabling factor for the implementation of a __hierarchical__ vehicle network in order to gain further quality enhancement and cost reduction of vehicles." la solution envisagee pour les commandes (lumiere, climatisation, porte..) dans la petites maison qui roule.
A+
XF

Numéro de l'article: 57858   |  De: XF   |  Date: 2003-11-17 15:41:25
   RE: Liaison série bi directionnelle
Salut
-----

Ecoute, j'abandonne.
Juste que tu aurais du aller charger mes documents sur mon site, tu aurais vu qu'on peut, si on veut, s'arranger pour que les paquets arrivent dans l'ordre. Tout est fonction de la façon de travailler, et de la fonction qu'on désire. Quand mes modules passent en mode bootloader, ils recoivent les trames dans l'ordre.

Un module en panne ne bloque pas le bus, il est désactivé en moins de quelques ms.

Mon système domotique, c'est un vrai système domotique, pas un pseudo-système qui ne comporte que des interrupteurs. Donc, débit important nécessaire.

Tu insistes avec ton RS485 avec maître, mais, avec ça, on ne sait pas faire un système domotique performant. J'ai besoin de 35 sorties gradateur rien que dans mon salon (éclairages d'ambiances personalisés), et d'une volée d'I/O par pièce (pas que des interrupteurs). Avec un système RS485, je suis obligé d'interroger sans arrêt toutes les cartes, c'est réellement peu pratique.
Et mon système est prévu pour piloter des grands systèmes, donc peut piloter plusieurs sous-réseaux. La domotique, ce n'est pas un interrupteur et 2 gradateurs, avec une alarme.

J'arrête là, les autres réponses, je les ai déjà faites dans les messages précédents.

A+
Bigonoff


Numéro de l'article: 57918   |  De: Bigonoff   |  Date: 2003-11-17 22:38:31
   RE: Liaison série bi directionnelle
Bonjour,
j'ai lu la presentation. C'est dommage, offrir des cours, les sources a la communaute et ne pas "precher"
pour l'ISO (pas un mot). C'est totalement FAUX qu'il soit necessaire d'avoir 500kbits/s pour la domotique.
meme pour regler un gradateur!. Comme c'est ecrit les systemes existants utilisent du 20kbits/s.
Cette valeur n'a jamais ete critiquee (vitesse LIN!). Le 500Kbits/s est necessaire dans le spectacle (domotique?), c'est la vitesse du DMX. En 2002, avec le LIN (domotique auto) les "industriels" allememands l'ont fait "dans son coin" (LIN1.0). Cherchant une certification ISO, pour ganrantir la perenite, ils ont ete oblige de revoir la copie avec un LIN2 INCOMPATIBLE avec le 1!. C'est pas grave car dans les faits le LIN1 n'est pas deployer, les modifs sont dans le "soft". Le filtre ISO est tres dur!!. Obliger microchip (PIC) et les autres 8051? DALLAS DS80C390 double CAN (tiens double?), pour la segmentation CAN?. La domotique s'oriente au "vert", petit, faible comsommation, segmentation du reseau(opto)(chapitre sur les precautions pour ne pas detruire le reseau). Ca c'est important, dans les reseaux 'habitations" (>100Kbits) il y a une isolation GALVANIQUE des stations, les transfos sont devenus INVISIBLES car dans la prise!!.Comme voiture=faraday pas d'opto, en industriel: opto pour le CAN. Des optos a 20Kb ok, chers a haute vitesse... Est ce que ca va marcher?, en se basant sur le document, un peu moins bien qu'une auto avec le CAN de 1er generation. C'est pas mal, car il y en a eu beaucoup de voiture. Probleme l'ABS: une charge importante, ce qui hormis lors d'un spectacle n'arrivera pas, et les datas... Un standard? non, la c'est dommage, car y a des exemples existent Linux....Soit, je critique, mais je trouve vraiment dommage de ne pas utiliser l'experience des autres, de l'ISO, la domotique, sujet tres interessant et enfin de commencer par la fin: imposer le CAN pour la domotique.
A+
XF

Numéro de l'article: 58065   |  De: XF   |  Date: 2003-11-18 23:25:10
   RE: Liaison série bi directionnelle
Salut
-----

Ecoute, je t'ai dit que je laissais tomber. Mais bon, vu que tu critiques directement mes applications (c'est ton droit), je réponds (c'est le mien).

Je réalise un système domotique (c'est mon second). J'utilise un débit de 500Kbits/s, je ne vois pas ce qui te pose problème. Je ne t'empêche pas de faire ton propre système. De plus, il est facile (et j'indique comment) de faire varier la vitesse du bus de 10 Kbits/s à 1Mbits/s, les sources sont fournies, il n'y a qu'une ligne ou deux à changer. Donc, celui qui voudrait absolument isoler galvaniquement peut le faire, tout est fourni : schémas, explications, sources, logiciels.

Moi, j'explique la méthode que j'ai retenu pour moi-même. Celui qui veut mieux faire le fait, celui qui propose autre chose le fait. Je vais même plus loin puisque j'indique qu'une fois le système de base réalisé, je publierai toute réalisation qu'on m'enverra sur le sujet sur mon propre site. Plus ouvert que ça, ce n'est pas simple à trouver.

Je n'ai pas dit qu'il FALLAIT du 500Kbits/S, j'ai dit que moi, j'utilisais du 500Kbits/s. Pour info, les bases de ce système sont utilisées simultanément sur des systèmes commerciaux, et mes choix n'ont pas été faits au hasard. J'avais le défit de faire passer un certain nombre d'infos dans un temps donné. Tu dis que le débit des autres systèmes n'a jamais été critiquée, c'est faux. Déjà, d'une part, parce que moi je la critique, et d'autre part je ne suis pas le seul. Le système que je développe est prévu pour le pilotage de grands ensembles (salles importantes, groupes de bâtiments, immeubles...), qui peut le plus peut le moins.

Je veux pouvoir réaliser le maximum d'application sans être géné par le débit maximum. Tiens, à propos, avec tes systèmes à 20Kbits/s, tu sais faire passer de la musique par le bus? (je dis ça comme ça, LOL). Mon système ne va pas se limiter à une carte gradateur, laisse moi le temps de développer les applications : cours, docs, cartes, logiciels, site, forum, boulot, tu crois qu'il me reste combien de temps pour dormir? Pour l'instant, il est 2H13 du matin, et demain je suis debout à 7H. Et encore, j'ai pris du retard, je n'arriverai pas à répondre à mon courrier aujourd'hui (et j'en ai, du courrier). Donc, avant de dire que 500Kbits/s ne sont pas nécessaires, attends de voir ce que je vais développer.

Ce que font les autres dans les systèmes domotiques ne m'intéresse pas (du moins pour le commercial). J'ai été invité à des démonstrations de systèmes domotiques officiels, et je n'ai pas (mais alors pas du tout) été convaincu. Ce sont des pseudo-systèmes domotiques, fort limités, genre : avec mon interrupteur de salon, j'allume la lampe du WC (ça intéresse qui?) et très chers (la dernière installation que j'ai vue coûtait 22000 euros). Moi, si je passe mon temps à faire mon propre système, c'est dans l'espoir de faire mieux et moins cher. Si c'est pour faire la même chose, je me contente de copier ce qui existe. Si je n'y arrive pas (on verra), c'est mon temps que j'aurais perdu, pas celui des autres.

Ceux qui cherchent la "pérénité" de leur système le font pour des raisons de compatibilités soit dans les versions futures, soit avec d'autres produits. Moi, je te le répéte une dernière fois, je n'ai PAS BESOIN d'être compatible avec autre chose, donc je n'ai pas à me plier à une norme ISO particulière, excepté celles imposées par le bus CAN.

J'ai reçu les mêmes réflexions pour l'ICD. Pour faire de l'ICD, il fallait un circuit compliqué, qui coûte assez cher, etc, c'était "impossible" de faire autrement (si si, on m'en a fait la démonstration), sinon Microchip n'aurait pas manqué de faire plus simple.

Résultat, j'ai fait le mien pour moins de 3 euros (et plusieurs semaines de recherches et de travail, et une collaboration avec Bonny Gijzen pour la modification de IC-prog pour gérer ça), et il travaille plus vite que celui de Microchip. La aussi, c'était inutile et impossible. N'empêche que d'après le courrier reçu, pas mal de personnes trouvent mon ICD pratique.

Le bootloader série sur n'importe quelle pin, c'était aussi inutile, vu que Microchip utilisait l'USART, on m'a même écrit pour me dire que je manquais d'intelligence, puisque je faisais autrement que Microchip. N'empêche que j'ai reçu pas mal de courrier de gens qui utilisent mon bootloader pour toutes sortes d'applications dans lesquelles l'USART n'est plus disponible (ben oui, c'était le but, Microchip semble ne pas y avoir pensé). Evidemment, c'était plus compliqué à créer que d'utiliser l'USART...

La méthode de travail qu'on voit un peut partout, c'est de piocher ce que font les autres (ce que tu me préconises), puis d'ajouter ou d'améliorer à partir ce ce qu'on a lu.

Moi, je procède différemment: Je ne lis strictement aucun ouvrage sur les questions qui m'intéressent, et je réinvente tout. Au besoin, je lis ensuite pour corriger ou pour améliorer. L'avantage, c'est que je ne pars pas d'idées préconçues, et donc j'obtiens des méthodes originales. Elles ne sont peut-être pas toujours meilleures, mais au moins on ne les retrouve pas sous 2000 versions différentes sur 3000 sites différents. Et ça, ça fait évoluer les choses : proposer du différent, et ne pas partir du principe que ce qui est déjà existant est forcément bon, puisque déjà pensé par d'autres.

L'ISO je n'en parle pas? Désolé, je parle de l'ISO qui intéresse les utilisateurs. Donc, dans mon cours, je parle de l'ISO7816. Les autres normes iso ne concernent pas la programmation des pics proprements dit. Mais rien ne t'empêche de faire des cours sur l'ISO et de mettre ça à disponibilité, ce sera tout bénéfice pour tout le monde (et j'irai lire, si si). Moi, désolé, je ne sais pas tout faire, j'ai des priorités.

Pour la protection CAN, je te suggère de lire le datasheet du MCP2551. 250V sur les pins de bus, protection jusque 6000V de CANH et CANL, et 4000V pour les autres pins. Note qu'une mise en application correcte des phénomènes ECM réduit (supprime) la nécessité des optocoupleurs même en cas de foudre. Tout est question de mise en place correcte. Avec ton système optocouplé avec alim directe sur les prises, tu auras l'air malin en cas d'une surtension arrivant sur le secteur. Moi, mon système va tenir. Avec tes cartes optocouplées alimentées sur les prises, ça va faire BOUM. Et oui, c'est facile de protéger une alimentation unique générale, mais protéger une alim par carte... En plus, placer une carte gradateur 16 sorties dans une prise, il faut pouvoir, LOL.

De plus, les cartes dont il est question actuellement sur le site sont placées de façon centralisée (hardwarement, à ne pas confondre avec la décentralisation des fonctions). Un optocouplage nécessite des alimentations séparées partout (très coûteux et inutile), alors que le simple respect des normes ECM permet d'éviter les problèmes (note que sans respect des normes ECM, tes optos seront de toutes façons pulvérisés en cas de choc de foudre, donc inutiles). Les optocoupleurs pour une liaison inter-site, oui, sur le même site, c'est inutile (exactement comme pour l'automobile si on a respecté le maillage des masses).

Mon système ne marchera pas mieux qu'un système auto de première génération? Si tu le dis, tu as sûrement raison. On verra à l'usage.

Pour ce qui est d'imposer le CAN, moi je n'impose rien à personne.
Je fais un système pour mon propre compte, et je propose d'en faire profiter les autres, c'est tout. Quand je vois les revues électroniques, qui ne proposent même pas les sources de leurs programmes, je me dis que ce n'est déjà pas si mal.

Pour ce qui est d'imposer les pics, je n'impose rien non plus. Mes cartes sont à base de PICs 18Fxx8, j'ai laissé 252 numéros de microcontrôleurs différents pour y mettre ce qu'on veut. J'ai créé le système, j'utilise les microcontrôleurs que je veux, c'est la moindre des choses. D'autant qu'il s'agit d'un site sur les PICS, je te le rappelle quand même. Toutes les sources sont données et documentées, et donc, puisque je respecte les couches ISO (si si) du CAN, n'importe qui peut créer une carte compatible avec mon système, c'est très simple (pour qui sait programmer). Maintenant, celui qui veut le faire devra se farcir lui-même le noyau bootloader, je ne vais pas m'amuser à faire des bootloaders pour tous les microcontrôleurs existants (et qui acceptent ce type de mise à jour). Mais, de nouveau, toutes les infos sont données pour le faire, il n'y "a qu'à"

La segmentation? Tu n'as pas du bien lire, parce que mon système incorpore la notion de "réseau", qui sont ce que tu appelles des "segments", donc des bus soit séparés physiquement, soit séparés uniquement logiquement, soit interconnectés directement ou par isolation galvanique (c'est strictement comme on veut).

Je n'ai que faire de l'expérience des autres en matière d'ISO, parce que mon système n'a pas besoin d'être compatible avec une couche ISO autre que celles imposées par le CAN. Je ne vois pas pourquoi je dois créer des compatibilités avec des normes avec lesquelles je ne communique pas, ça n'a aucun sens. Tu parles des standards. Tu rigoles? Il n'y a pas deux systèmes domotiques sur le marché qui soient compatibles, alors les standards, permet-moi de rigoler. Et je ne vois pas ce que Linux vient faire dans l'histoire ???

L'expérience des autres servirait si je voulais m'intégrer dans un système existant, ce n'est pas le cas (je ne sais plus comment le dire, peut-être en chanson?)

MAintenant, de nouveau, rien ne t'empêche de faire un autre système, avec tout l'ISO que tu veux, et de mettre tout ça sur un site gratuit, avec les docs et les sources, afin que tout le monde en profite. Comme ça, on aura un exemple pratique et utile de ta façon de concervoir les normes ISO.

Pour ma part, je n'ai pas le temps de commencer à disserter sur mon site sur les centaines de normes ISO, et d'analyser pourquoi je n'utilise pas telle ou telle norme existante. Sans ça, mon site serait un site sur l'ISO et pas un site sur les pics. Il faut choisir, je n'ai plus de temps supplémentaire à consacrer.

A titre d'information, quand je fais une carte pour moi, il me faut plus de temps pour écrire la doc que pour faire la carte. Or, la doc, je ne la fais pas pour moi. Je ne peux pas faire plus que ce que je fais, j'y passe déjà mes nuits et mes W.E. A toi la main pour réaliser quelque chose de meilleur ou pour parler d'ISO (OSI in french)

A+
Bigonoff


Numéro de l'article: 58265   |  De: Bigonoff   |  Date: 2003-11-20 02:29:33
   RE: Liaison série bi directionnelle
XF tu dis n'importe quoi Bigonoff a raison sur la fiabilité des trames. J'ai travaillé chez un constructeur automobile et je connais bien le pb.
On voit bien que t'as rien compris quand tu dis que certaines trames ont la même prioritée!!!!lolll
BRAVO POUR CETTE JOUTE EPISTOLAIRE TRES DISTRAYANTE.


Numéro de l'article: 58318   |  De: ced   |  Date: 2003-11-20 13:35:15
   RE: Liaison série bi directionnelle
Bonjour,
Ced: au sujet des trames, j'ai du mal m'exprimer, evidement la collision en CAN permet la gestion de la priorite, mais dans le cadre de l'exemple, ca peut poser un probleme.
Ce n'est pas sans raison que microchip a ajoute ceci dans la doc du MCP2515:
• One-shot mode ensures message transmission is
attempted only one time
" One-shot mode is required to maintain time slots in
deterministic systems, such as TTCAN."

Et chez un constructeur... a l'epoque ca n'existait pas "d'office".
C'est vraie que le CAN ca marche bien, mais dans le service "bug rare", deformation professionnelle?.C'est pour cela que j'insiste : quoi qu'on fait avec!!.
Au niveau musique: le coax et la video? et a min 10Mbits/s. C'est isole galvaniquement, pas cher. Par contre, le min pour la maison, "controlable", la je suis d'accord.
Meme le DMX (RS485) est isole galvaniquement des stations. Au niveau domotique, j'avance comme la tortue ( et le boulot) , j'ai (sur la table!)du LIN, ca decante, et j'observe la normalisation LIN, (ils en sont a la version deux) pour pas avoir a le refaire!.
XF










Numéro de l'article: 58346   |  De: XF   |  Date: 2003-11-20 15:53:52
   RE: Liaison série bi directionnelle
Demmande des motoristes , entre eux: Lecture correcte:CRC, pas de soft: multimaitre,
priorite naquit le CAN 0. Puis il a evolue au gres des problemes.
Probleme: sonde HS (en analog: -200degre, +1000..), en CAN: derniere valeur!!!.
Rustine: soft, datation, alarme si plus de nouvelle l'application de MULTIPLEXAGE d'origine
a du avoir une rustine, ca aurait pu etre prevu
C'est pas dans le CAN?: fonction multiplexage, pas d'assurance sur "la presence du capteur".
Probleme: module CAN "secoué": bloque le bus solution: rideau par un compteur d'erreur.
Probleme: ABS, vie humaine en jeu. Un module peut bloquer (Temps de rideau = accident), ou pas
laisser passer les autres (dit"surcharge"?!!): pas de priorite "tourannte": modif en soft,
mieux en hard...microchip. Enfin: les donnees: l'CAN X25. L'option systeme et reseau en fac c'est ca (bonne lecture); pas l'beurre et l'argent du beurre. Un bus c'est comme le porc salut, c'est ecrit dessus!.
USB1: trop court pour la video (10Mbits/s): USB2 (480Mbits/s). Au niveau EQUIPEMENTIER y a une
guerre des prix, microchip veut "sortir" le 8051 de l'auto ca va prendre? a suivre...
Sinon dans 5 ans y a plus rien, pire (histoire vraie)un mois apres la recette final: arret de fabrication du chip principal, recent. D'ou le basic, le multisource mais c'est encore un autre aspect
des choses, il est plus difficile de maintenir du materiel de 7 ans d'age que de 25 ans.Vive le 7400!!.
En hard: RS232 point a point, dehors, LIN: bus collecteur ouvert (MUTISOURCE!!), minimal, fonction?ISO? a voir. RS485, idem, plus rapide, CAN "moins evident" (pas en SOFT!!), trop court pour le mutimedia. Interphone? RS485 passe.
Enfin le connecteur?: 4 points necessaire. En CAN?, le 9 points (deux CAN!!). Blinde, le prix du m (a comparer au prix du chip PIC), bretelle: pas possible (excusable en segmente, faible vitesse): DB9 sur cable plat, facile a monter. Enfin, je dis pas POMPER le SOFT, je dis GNU: a lire. ON AJOUTE une pierre, c'est COMMUNAUTAIRE. Parceque tout seul, on peux ni changer ni faire le monde...
A+
XF

Numéro de l'article: 58372   |  De: XF   |  Date: 2003-11-20 18:36:34
   RE: Liaison série bi directionnelle
SAlut
-----

un dernier.

Tu me parles du can0, je te parle de la version 2.0b. Quel rapport????

"En CAN, dernière valeur". Tu rigoles? Un buffer, tu sais ce que c'est? Ton message, tu l'as reçu, tu en fais ce que tu veux. Un message n'écrase jamais le message précédent, c'est n'importe quoi de dire ça.

Ton bus à 100Mbits/s en coax ??? Essaye d'implémenter ça sur un microcontrôleur, LOL. Je ne veux pas piloter ma maison avec un PC de 400W, je pilote par cartes à microcontrôleurs.

L'absence d'un module CAN? Ben oui, et alors, où ai-je dit que si on enlève un module on a une erreur ??? J'ai dit : trame d'erreur pour tout module PRESENT. Tu penses que mes cartes vont se déconnecter toutes seules?

Et de toutes façons, si j'enlève une carte gradateur de mon système, j'aurai beau le savoir, ça ne me permettra pas d'allumer la lampe. Donc, il faudra de toutes façons intervenir, QUEL QUE SOIT le bus utilisé.

De plus, je t'ai dit que j'avais des mécanismes qui permettent de s'assurer de la présence d'une carte. C'est très (TRES) simple à implémenter, pas besoin de se perdre dans des protocoles compliqués.

Tu dis : augmente la sortie de la lampe 3 de 10. La carte répond : ok, la nouvelle valeur est de 26. C'est compliqué? Ce n'est pas sûr? Il faut encore un autre protocole?

Par contre, en cas de panne d'une carte, ma carte va se déconnecter automatiquement du bus. Avec ton RS485, tout est en panne avec un peu de malchance. Alors, tu auras beau avoir implémenté des détections softwares, tout sera bloqué.

Les bugs de Microchip? Et alors? Tu en veux toute une liste? Tu sais que les modules I²C ont un bug en multimaître? Ce n'est pas un défaut de l'I²C, c'est un bug dans le module Microchip. Ca n'a strictement rien à voir. Du reste, je n'utilise pas de MCP2515, j'utilise un MCP2551. Le MCP2515 est un gestionnaire séparé de bus CAN, le 2551 est un driver de bus CAN. La gestion est assurée directement par le PIC, c'est plus simple et plus économique.

Le one-shot, ça sert dans des protocoles spéciaux. En a besoin qui veut. Ce mode a été ajouté pour se rendre compatible avec ce qui existait déjà, et non le contraire. Moi, je n'ai pas besoin de "one-shot", parceque je n'ai pas besoin que mes trames soient incluses dans un créneau temporel déterminé. J'ai besoin que mes trames arrivent, point. Note que, du reste, c'est le contraire de ce que tu affirmes depuis le début, puisque le "one-shot" est là pour EMPECHER la réémission automatique des trames en erreur, alors que cette réémission est bel et bien automatique par défaut. Sommes toutes, ça permet de "dégrader" le CAN à un niveau du genre RS485, ou tout doit être géré par soft.

Le basic? Tu rigoles? Avec une perte d'efficacité d'un facteur 10 à 100 selon l'application. Même le meilleur basic compilé a une perte d'un facteur 10 dans le meilleur des cas. Et dans les applications complexes, on atteint 100 (je parle compilé, interprété c'est une dégradation de 1000 à 10.000)

En RS485, connecteur 4 points, 9 en CAN? Soyons sérieux. Tu confonds une des normes de connecteurs utilisés (il y en a plein, du DB9 au RJ10) avec le nombre de lignes nécessaires. En CAN : 2 fils, c'est tout.

Comparer le prix d'un driver avec le prix d'un PIC. LOL. Et ton driver, il te ne te faut pas un contrôleur pour le piloter? LOL

Le double CAN? Inutile pour ce genre d'application. Ou alors, c'est pour avoir de l'ultra-sécurisé. MAis, dans ce cas, il te faudra également un double RS485 (bonjour pour gérer par soft).

Le GNU? Qu'est-ce que ça vient faire la-dedans. Le GNU c'est une charte qui précise les modalités si on veut faire des programmes publics. Les miens sont publics, commentés, avec les sources. Alors, je n'ai pas de leçon à recevoir du GNU.

Le GNU ne m'intéresse pas, parce qu'il est dit dans la réglementation qu'on peut modifier tes applications et en faire un produit commercial.

Alors, oui pour tout partager, mais si c'est un autre qui fait du fric sur base de mon travail, c'est une limite que je ne franchis pas. Mon travail reste et restera gratuit. Et si quelqu'un devait faire de l'argent avec, ce serait moi, pas un "copieur". C'est pour ça que j'ai refusé la réglementation GNU (généreux, mais pas fou).

Ajouter la pierre à l'édifice? Ben oui, ce n'est pas ce que je fais? J'avais cru. Plus que ça, je ne sais pas, désolé.

La guerre des équipementiers? Ben oui, tu débarques de quelle planète? La guerre, elle a toujours été là : soit on se fait la guerre, soit on s'allie. En dehors, point de salut. LE 8051, il est tout de même vachement obsolète, il est temps de tourner la page (et je sais de quoi je parle, j'ai programmé en 8051), même si les dernières versions (mémoire flash, modules etc) sont meilleures que les premières.

Ecoute, plutôt que d'argumenter dans le vide pendant 6 mois, je te propose la solution suivante :

- Je fais mon propre système domotique sur base du CAN
- Tu fais le tien, sur base de ce que tu veux

Au final, on met tout en ligne, et les utilisateurs comparent et choisissent.

On verra aussi ce qu'il est possible de faire avec un système, et ce qu'il est possible de faire avec l'autre.

C'est pas plus simple?

A+
Bigonoff


Numéro de l'article: 58390   |  De: Bigonoff   |  Date: 2003-11-20 22:46:36
   RE: Liaison série bi directionnelle

Bonjour,
je n'ai pas dit qu'il y avait des bugs chez microchip. C'est un resume des problemes du CAN. Le one shot a ete fait pour resoudre un pb de deterministe, temps d'actions rapides. c'est pas en contadiction avec l'CAN X25 (DATA), c'est encore autre chose. Oneshot+CANX25(buffer)= systeme deterministe (rapide)+DATA, mais plus MULTIPLEXAGE!!. Oui, le 8051 y a mieux, mais tout les labos (equipement) ont les outils, le soft, leurs "moniteurs multitache normatif ;) " etc, et des nouveaux micros sortent c'est pour cela qu'il est "indeboullonnable". Micro chip veut faire de l'auto, le chip est cible: auto, pas d'UART. Ils ont fait le tour: MULTIPLEXAGE, DATA (le FIFO) et le one shot. Les 3 "fonctions auto CAN". Il "drague" l'auto. d'ou le "a suivre"...

Un bus c'est fragile, meme avec les "protections", c'est pour cela que l'isolation galvanique devient le standard.

Solution: redondance on double, pour avoir "toujours" l'ensemble OK, soit on segmente, avec de l'isolation galvanique entre chaque compartiment, comme "un sous marin", on perd un bout. Le LIN: le min pour avoir les fonctions "domotiques". Faible cout: objectif LIN dans 12C508?.

Un cahier des charges, le "decantage", voir autour, le pourquoi "ca"?. Evite souvent des erreurs.

Le CAN c'est 3 fils min, 4 avec l'alim. A cause du courant d'alim: le CAN: DB9 (RJ45 pas telephone), en pro, 3 fils: XLR (DMX). LIN 'faible courant' RJ45, ou DB9 cable plat (plusieurs points?): motif: facilite de cablage/Prix.

Je fais pas la course a sortir un produit(temps), par contre, pour l'ensemble des lecteurs du forum qui veulent faire de la domotique, le debat me semble interesant.

Au niveau du soft, "gratuit" (vague) c'est le mettre dans le domaine public, donc quiconque peut le modifier et en faire un produit commercial (sans source).
Extrait info sur GNU GPL:
"Considérons le GNU C++. Pourquoi existe-t-il un compilateur C++ libre ? Uniquement parce que la GNU GPL indiquait qu'il devait être libre. MCC, un consortium industriel, a développé GNU C++ à partir du compilateur GNU C. En temps normal, MCC rend sa production aussi propriétaire que possible. Mais ils ont fait une interface C++ libre parce que c'était la seule possibilité de l'éditer que leur laissait la GNU GPL. L'interface C++ comportait beaucoup de nouveaux fichiers, mais comme ils étaient prévus pour être liés à GCC, la GPL s'appliquait à eux. Le bénéfice pour notre communauté est évident. "
Tout nouveau produit a partir du GNU GPL, restera libre (source obligatoirement disponible).
c'est mieux?... et ils ont des avocats... (pot de fer contre terre).

A+
XF


Numéro de l'article: 58474   |  De: XF   |  Date: 2003-11-21 19:12:00
   RE: Liaison série bi directionnelle
Salut
-----

1) Le bus CAN, stop, je ne vais pas dire 100 fois la même chose. Garde tes convictions (fausses), je ne cherche plus à te donner d'argumentation, tu ne les prends pas en considération.

2) Je ne vais pas doubler mon CAN, je pilote une maison, pas un boeing

3) Ton RS485, à côté du CAN, ça fait pour le moins "primitif" niveau sécurité. Mais bon, je ne cherche plus à te convaincre.

4) On n'a aucune raison de "perdre un bout de bus". Tu ne sembles pas expert en bus.

5) Je sais ce qu'est un cahier des charges, merci. Je te signale que je développe des applications commerciales, et dans des domaines très critiques. Tu crois que je développe sans réfléchir à ce que je fais???

6) Le CAN, c'est deux fils minimum, désolé. On n'envoie pas la masse sur un codage différentiel. Revois ta copie. Si on ajoute l'alim, ça fait 4, mais c'est pareil pour le RS485.

7) Le DB9 n'est pas l'unique connecteur CAN officiel, on voit que tu ne connais pas correctement le CAN, relis (ou plutôt lis) la norme officielle : CIA DR-303-1 : RJ45; RJ10, différents connecteurs DIN etc sont au programme des connecteurs officiels (avec les brochages normalisés correspondant).

8) Aucun standard domotique n'a jamais réussi à s'imposer, il n'y a donc PAS de standard officiel. Lin, X10 et autre, chacun fait comme il l'entend, chacun veut être le seul, et personne n'y arrive.

9) Rien ne t'empêche d'utiliser le standard de ton choix, rien ne m'empêche d'utiliser le mien.

10) Le GNU ne se limite pas au C++. Programmer en C++ sur un PIC est une hérésie.

11) Tu es très mal renseigné sur le GNU, moi je suis renseigné puisque j'ai eu contact pour y placer mes cours. Pour être GNU, tu dois accepter que ton travail puisse être utilisé par tous, MEME pour des applications commerciales. Tu ne peux plus rien revendiquer.
AUtrement dit, j'écris un bouquin "GNU", un auteur xxx s'en empare et l'édite commercialement, je n'ai aucun droit dessus.
Alors, le GNU...
Par contre, mettre comme j'ai fait, une distribution libre, avec preuve que j'en suis l'auteur, INTERDIT (oui oui) toute application commerciale sans mon consentement, je reste propriétaire execlusif de mes cours. Un exemple, le GIF, qui était public, est redevenu privé, personne n'a le droit actuellement de l'utiliser sans license. Et pourtant, c'était public il y a 3 ans. La situation est donc exactement l'inverse de ce que tu dis. Tu débats sur des sujets que tu ne maîtrises pas, c'est mon avis.

12) Il n'y a pas besoin du GNU pour avoir des programmes libres, il en existe des centaines non "GNU". Je fais du gratuit non GNU, et ça ne semble déranger personne. J'autorise tout usage privé, et c'est ça qui compte.

13) Je sais ce que signifie "one-shot" et quelle est l'utilité, merci. Ce n'est pas signe d'un défaut du CAN. Pour info, tu as exactement les mêmes possibilités sur un réseau HF de type WIT2410

14) Les outils de développement sur pics ont un coût dérisoire, ce n'est pas ça qui va cantonner une société sur le 8051. C'est plus souvent la paresse d'étudier autre chose.

15) Je me sens subitement fatigué, là, LOL

A+
Bigonoff


Numéro de l'article: 58559   |  De: Bigonoff   |  Date: 2003-11-22 13:18:51
   RE: Liaison série bi directionnelle
Bonjour,

1) Pas de "conviction", les motifs de la creation et de l'evolution du produit.
La confrerie des motoristes ont la conviction que le CAN est le plus beau bus du monde.... (c'est presque vrai!!)Les utilisateurs (l'argent) ont obliger les patrons (constructeurs) a prendre l'avis motive "d'exterieure". L'CAN X25 et le one shot a fait crincer des dents dans la confrerie.
2) Une panne sur une table pas grave, mais dans une maison, tout HS.. reseau CUIT.
3) CAN contre RS485 non!!, "caler le produit a l'objectif visé" un char pour une noisette!!...
4) Pas un bout l'ensemble, d'ou la segmentation, et l'opto isolation isolation galvanique.
5) Le cahier des charges consiste a placer le CAN?. Il est bien plus complexe...
6) Le CAN deux fils?. La y en a qui doivent se retourenr dans leurs tombes!!.
La masse FIXE le mode COMMUN!!. Il ne PEUT pas ETRE INDEFINI avec des semi conducteurs!!. OBLIGATOIRE.
Seul le TRANSFOS l'autorise (la masse devient l'ecran). Le "ca marche" n'est pas UNE DEMONSTRATION, c'est une "table"... Lire le cours sur l'AOP et la documentation de TOUT CI "MAXIMUN MODE COMMUN MODE".VCr= VCe+Vx?.Avec la masse: VCr=VCe!!. Pour eviter ce stress MORTEL on allonge la masse (premier contact) sur les connecteurs "jeunes" USB...
ex: PCA82C25 "LIMITING VALUES (destruction)" -8<VM<+18 par rapport au GND (pin2), et si pas relier? (VX?)!!.
Dans les DEUX "exemples d'applications" la MASSE est TOUJOURS presente (avec ou sans isolation galvanique,
par opto = application voiture / application industrie.
7) Evidement que le DB9 n'est pas le seul, le choix se porte en fonction du choix, avec ou sans energie, facilite de cablage (sertissage DB9, HE10), cout.
8) Aucun standard, oui. NON, certains definissent leurs besoins, compare avec les normes, quittent a revoir leurs copie, comme le LIN.
Ils ne sont pas encore au bout du chemin.
9) Un standard c'est avant tout une mise en commun "Mon standard".
10) C++ C'etait l'EXEMPLE du GNU pour expliquer le maintien dans la communaute.
Pragmatique: 3 solutions: l'edition(= argent), libre (ARGENT= autres tant pis), communautaire
(ARGENT= Sans benefice a cause de la license). Solution 4: seul? le pot de fer contre le pot de terre.
surtout sur un cour.. un plagiat presque par definition!!. Et JUSTICE = ARGENT.
11) Au prix coutant, c'est pour cela que ce qui est "publique" n'est pas RENTABLE pour l'EDITEUR.
12) libre (ARGENT= autres tant pis): j'ai fait... OM.
13) "one shot" si "la confrerie" avait pu s'en passer ... mais OBLIGATOIRE pour le CLIENT.
14) Les outils, oui avec le PIC ( ou le 8051) on peut le faire simplement. Mais c'est un "outils" par personne, une license.
Et aussi VALIDATION des PROGRAMMEs, des COMPILATEURS (C)... transport des programmes... Repasser les homologations...
un cout.... La NASA prefere chercher des vieux 80188s plutot que de valider un portage!!.Et EQUIPEMENTIER = ARGENT.
Alors faut vraiment "draguer" pour sortir le 8051 en CAN ca "existe".
Le LIN non!!...
A+
XF


Numéro de l'article: 58754   |  De: XF   |  Date: 2003-11-23 22:47:35
   RE: Liaison série bi directionnelle
Salut
-----

Je te laisse à tes convictions, étant donné que plus personne ne suit ce vieux post.

Etudie également le fonctionnement du MCP2551, c'est un conseil.

Quant au coût des logiciels gratuits, je te laisse méditer.

Dire que le top c'est l'isolation galvanique, et dire en même temps que la connexion des masses est obligatoire me semble pour le moins curieux.

Je te déclare vainqueur par abandon

Moi, je retourne travailler à mes applications qui ne fonctionnent pas.

Un petit lien sur le CAN en automobile (bien qu'on cite d'autres applications, dont la mienne)

http://www.sar.admin.ch/fat/m/download/ulr5ef.pdf

Quelques autres liens :

http://edelaunay.chez.tiscali.fr/buscan.htm

http://www.enseirb.fr/~kadionik/formation/canbus/canbus.html (voir connexions physiques sur 2 fils)

http://www.a2v.fr/program/cbm.htm (applications non automobiles)

http://www.oberle.org/can-index.html


Un résumé en quelques mots :

http://www.diaverre.com/materiel/can.htm

Ainsi, chaque personne intéressée pourra se faire sa propre opinion (note qu'il est dit au moins 20 fois que l'avantage principal du CAN est une liaison à haute vitesse avec un haut degré de sécurité, avec bus sur câble différentiel (insensible au mode commun par définition)).


A+
Bigonoff


Numéro de l'article: 58905   |  De: Bigonoff   |  Date: 2003-11-25 00:05:13
   RE: Liaison série bi directionnelle
Euh pour répondre à ta question qui est le but de ce post, tu devrais pouvoir utiliser un protocole I2C non? en 10 bits, ca devrait suffir pour les adresses? Maintenant, si tu sais faire du FPGA, tu peux meme choisir toi meme ton format d'adresse... Mais bon, tout dépend des données que tu as à faire passer...

Numéro de l'article: 58961   |  De: pazcal   |  Date: 2003-11-25 15:25:15
   RE: Liaison série bi directionnelle
Bonjour,
La masse est obligatoire pour rester CONFORME AU VALEURS MAXIMALES en MODE COMMUN des COMPOSANTS.
ON DOIT RELIER LES MASSES EN CAN.
EVIDEMENT que le MODE DIFFERENTIEL est choisi parceque INSENSIBLE aux parasites de mode COMMUN.
Si on veut une ISOLATION GALVANIQUE: soit le transfos (passe pas le continu!) soit l'opto isolation.
Elle est quasiment toujours utilise hors de la voiture.
ELLE ISOLE la STATION DU RESEAU.
En CAN comme en RS485 on la place entre le driver et le controlleur.
Il suffit de lire la DOC d'un driver pour avoir l'epplication type.

EVIDEMENT que le CAN AUTOMOBILE fonctionne, j'en ai fait.
Je DIS QU'il est PREVU pour un TYPE de FONCTIONNEMENT.
Que L'AUTOMOBILE, avec SON EXPERIENCE et l'ANALYSE ISO a pour les APPLICATIONS (cf messages precedents) AJOUTEE des COUCHES de PROTOCOLES. J'AI AUCUNE conviction, je constate SUR PIECES: ISO et one shot. Le premier, je l'ai vu, le second etait connu.
MICROCHIP a fait des nouveaux circuits, il a l'avantage de les sortir en tenant compte des dernieres "pieces".
A+
XF




Numéro de l'article: 59034   |  De: XF   |  Date: 2003-11-26 00:30:31
   RE: Liaison série bi directionnelle
Salut
-----

LOL.
Jette un oeil sur les liens, c'est instructif.
PS : c'est pas la peine de "crier", LOL

A+
Bigonoff


Numéro de l'article: 59175   |  De: Bigonoff   |  Date: 2003-11-27 00:01:25
   RE: Liaison série bi directionnelle
oui
"Le protocole CAN de base leur permet d'échanger 2048 variables."
ca c'est le multiplexage... (http://edelaunay.chez.tiscali.fr/buscan.htm)

cours: tension sur la paire diff (dessin) par rapport a 0V!!
La masse!!
Comment definir la tension si les masses ne sont pas reliees?
C'est le ba ba de la transmission (mode commun)!!.
Oui, c'est un bus differentiel, mais la masse est INDISPENDABLE..
C'est pas par conviction c'est par demonstration...
XF




Numéro de l'article: 59177   |  De: XF   |  Date: 2003-11-27 00:21:50
   RE: Liaison série bi directionnelle
Salut
------

Lis les liens... correctement, LOL

petit abc electrique : une "tension", ça n'existe pas dans l'absolu, une différence de potentiel, oui.
2 fils = différence de potentiel = signal.

A+
Bigonoff


Numéro de l'article: 59294   |  De: Bigonoff   |  Date: 2003-11-28 01:05:05
   RE: Liaison série bi directionnelle
Bonjour,
faut etre zen..heureusement j'ai la fibre pedagogique.
VE=VM+VS est la demonstration mathematique de l'obligation de la masse.
Les exemples sont legions. Pour l'EDF, la tension de mode commun VM
peut faire sauter le reseau, car meme en reliant les masses,
sur des centaines de KM VM n'est pas nulle.
Lors d'un electrocardiogramme (mesure differentielle), le 3ieme fils "fixe" le mode commun.
Entendre VM?: Branche sur ton ampli seulement l'ame d'une source: le ronflement c'est VM.
Le CAN est en differentiel.... Au lieu d'une entree, les deux seront saturees par le 50Hz!!.
Et quand l'etage d'entree est saturée, il ne fait plus la difference!!...
La sentir?la tension peut etre importante, plusieurs centaines de volts, branche une antenne de TV
en touchant les masses. Quand a la bibliographie, la demonstration cite plus haut de mes vieux
cours me suffit.. Je suppose que l'oublie vient du fait qu'on s'interesse au transfert de
l'information uniquement. Les autres conditions pour un transfert correct
(la maitrise du mode commun ici) ne fait plus partie du cours.
"Mais c'est faux parceque meme sans la masse ca marche"....
Oui, le rebouclage de VM se fait par les circuits de protections, qui normalement ne doivent pas
etre mis a contributions. Ils recoivent tout VM, en particulier lors d'un branchement du secteur.
En general ils ne restent pas longtemps en vie.
Stop ou encore?
A+
XF

Numéro de l'article: 59675   |  De: XF   |  Date: 2003-12-01 14:09:42
   RE: Liaison série bi directionnelle
Salut
------

Tu confonds plusieurs choses.

La distribution EDF n'a rien à voir parce qu'il y a une mise à la terre du neutre. Tes montages connectés à l'EDF étant reliés à la terre par le conducteur de protection, il est impératif d'interconnecter les masses. C'est une question de sécurité élémentaire. Pas de ddp entre masses = pas de danger.

Tu ne peux pas avoir de ddp entre 2 fils de deux circuits électriquement séparés, sorry. Car, s'il y avait une ddp, il y aurait un courant possible, donc les circuits ne seraient pas séparés.

Tu ne peux pas non plus additionner deux tensions qui n'ont pas de référentiel commun. Si un transfo me donne 12V et un autre transfo 18V, je n'ai aucune ddp entre les deux transfos tant que je n'interconnecte pas ensemble un des fils de chaque secondaire.

Si j'allume une led d'un optocoupleur à 1000m de distance avec un câble twisté, même si j'ai une "tension" à 50Hz de 10.000V par rapport à la terre sur mes deux fils, ma led ne recevra que le courant circulant en mode différentiel dans les deux fils. Pourquoi? Parce que la led reçoit U1 - U2, quelle que soit la "valeur" de U par rapport à la masse distante.

Rien ne pourra claquer, sauf si le 10.000V peut amorcer par rapport à la terre. A ce moment, le circuit se retrouve fermé par la terre.

Note qu'il suffit de référencer un des fils à la terre à une extrémité (sans même relier les masses), pour éliminer ce problème.

C'est pour éviter ce problème de claquage sous très haute tension que j'ai préconisé sur mon site d'utiliser un câble blindé, référencé à la terre en plusieurs points, et que j'ai utilisé une interconnexion de toutes les masses et une alim commune. Donc pour éviter les problèmes dûs à la foudre. Alors même, et je te le signale, que toi, tu préconisais d'isoler galvaniquement et d'utiliser des alimentations séparées (bonjour pour isoler à des tensions de plusieurs milliers de volts).

Donc, hors claquage H.T., aucun problème. Pour éviter les claquages, maillez les masses. Mais ça n'a rien à voir avec les courants "mode commun" et la nécessité d'une masse pour le signal différentiel.
C'est une précaution pour éviter toute ddp entre masses et terre, et donc éviter un claquage par la foudre (qui seule, induit de grandes tensions entre masses et terres).

Toi, tu préconises exactement le contraire : interconnecter les masses au niveau du circuit différentiel, et isoler galvaniquement les parties commandes, alimentées à partir des prises de courant.
En cas de choc de foudre, ça c'est destruction instantanée. Si tout est maillé, on passe au travers.

Sur un électrocardiographe, le ou les fils de références servent à annuler la tension parasite issue principalement du rayonnement secteur. C'est logique car le patient est soumis à une ddp à 50Hz superposée au signal utile. Il faut donc une astuce pour soustraire ce signal. Cette astuce est une symétrisation de la liaison.

On a une ddp entre A et B qui vaut ddp utile + ddp parasite

Si on fait A - B, on a la ddp utile et la ddp parasite.
On n'a donc aucun moyen de séparer le signal utile du signal parasite.

Donc, on ajoute un point C, on a donc 3 ddp (A-B), (A-C) et (B-C). Par soustraction entre les différentes ddp, on arrive à obtenir ddp utile, puisque ddp utile n'est présent qu'entre A et B.
Je suis bien placé pour le savoir, j'ai travaillé 12 ans dans le secteur médical, des scopes j'en ai vu et étudié.

Dans un montage différentiel, la situation est toute différente. Prenons par exemple :

- Pour exprimer un niveau 0, j'ai une ddp de 5V entre A et B
- Pour exprimer un niveau 1, j'ai une ddp de -5V entre A et B

En effectuant A - B, je récupère toujours mon signal utile. Nul besoin de fil supplémentaire.

Pour la "tension" superposée à A et B (identique), elle ne m'importe pas. D'une part, parce que "tension", ça ne veut rien dire si on ne dit pas par rapport à quoi. SI donc c'est une tension par rapport à la terre et que mon montage est isolé de la terre, je m'en tamponne, LOL

Et d'autre part, parce que la seule "tension" qui pourrait être néfaste serait une "tension", ou plutôt une ddp par rapport à la masse locale de mon montage.

Donc, il me suffit de référencer A ou B ou les deux (pont de résistances) à ma masse locale, pour ne plus avoir aucune ddp parasite. Ou alors de n'avoir aucun courant possible (isolation totale), et donc plus aucune ddp. Une "tension" dans le "vide", je m'en fous.

Et ça n'induit aucun courant s'il n'y a pas de chemin de retour entre ma masse locale et ma masse distante, donc si les montages sont isolés galvaniquement. Donc, aucun risque pour quoi que ce soit (sauf foudre par amorçage).

A partir du moment où je relie les masses locales à la terre, par exemple, là je cours un risque qui m'impose d'interconnecter les masses. Comme c'est plus simple d'assurer l'équipotentialité des masses que l'isolation galvanique, c'est préférable d'interconnecter, mais pas indispensable. Du reste, je n'ai dit nul part le contraire, et heureusement puisque c'est le schéma pratique que je donne sur mon site.

Si j'applique un signal différentiel à un montage dépourvu de point commun avec la terre, je ne suis pas soumis à une saturation des étages d'entrées, puisqu'il n'y a pas de chemin pour la circulation d'un courant en mode commun. Toujours parler courant et ddp, et pas "tension". Le câble en différentiel, il est référencé à la masse locale. Donc, je n'ai jamais que la ddp différentielle appliquée sur les entrées, par définition même.

Maintenant, c'est clair que si j'utilise la même alim, je dois relier les masses, mais c'est fait automatiquement, puisque j'ai la même alim (comme dirait Lapalisse). Du reste, je n'ai jamais déconseillé de relier les masses (c'est fait sur le schéma de mon site), j'ai dit qu'on pouvait interconnecter deux cartes CAN isolées galvaniquement à l'aide de deux uniques fils différentiels. Du reste, sur les sites dont je donne les liens, c'est clairement expliqué.

Si tu as deux montages isolés galvaniquement reliés par une paire différentielle, il n'y a pas de courant en mode commun qui circule dans la paire différentielle, car il n'y a aucun chemin de retour.

Ton problème, c'est que tu parles partout de "tension". Or, la tension, dans l'absolu, ça ne veut rien dire. Seules les ddp et les courants ont de l'importance.

Pour ton ampli, c'est clair que si je ne relie que l'âme, j'ai un ronflement 50Hz. En fait, d'une part je n'injecte pas de ddp "signal", puisque je n'ai qu'un seul conducteur. donc, déjà, ça pose problème. Pas de ddp = pas de signal. D'autre part, là j'ai un mode commun (encore que, un mode commun sur un seul fil, mais bon), puisque j'ai un courant qui se referme par la masse du montage cible. Cette masse est couplée à la terre et aux autres masses de façon capacitive ou directe (masses reliées à la terre). En réalité, j'ai donc injecté une ddp 50Hz entre la masse de ton ampli et le conducteur d'arrivée du signal.

Mais si je prends un accu de 1000V et que je relie la borne positive de l'accu à l'âme de l'ampli, je n'aurais ni plus ni moins de bruit.
Et si je relie la borne négative de l'accu à la terre, je n'aurais aucun dommage sur mon ampli, à condition qu'il soit isolé galvaniquement de la terre.

En suivant ton raisonnement "tension", tu me diras : j'ai 1000V sur l'entrée de l'ampli, donc destruction.

Moi, je dis, j'ai une ddp de 1000V entre l'entrée de l'ampli et la terre, mais vu que la masse de l'ampli n'est pas reliée à la terre (dans mon hypothétique exemple), je n'ai pas de ddp entre l'entrée de l'ampli et la masse de l'ampli, donc aucun problème.

Je vais plus loin. Toujours avec mon ampli isolé galvaniquement, je mets une ddp de 1000V entre l'âme du câble et la terre, et une ddp de 1000V entre la masse du câble et la terre.
Et bien, mon ampli va fonctionner de façon tout à fait correcte, et sans aucun risque. Certes, c'est dangereux pour l'utilisateur parce que la masse de l'ampli est à 1000V par rapport à la terre, mais ça fonctionnera sans problème. Note que c'est dangereux uniquement parce que je me suis amusé à référencer la borne négative de l'accu à la terre. Si je ne connectes pas la borne négative, j'ai une "tension", mais pas une ddp.

En effet, la masse locale de l'ampli et reliée à la masse du câble, donc ddp = 0. la ddp entre l'entrée de l'ampli et la masse de l'ampli (ddp utile) vaudra (ddp utile + 1000V) - (1000V) = ddp utile.
Aucun dégât, aucune perturbation, aucun mode commun, car par de courant de retour.

Les paramètres ECM, et le mode commun, je connais. Je te conseille d'ailleurs de lire les 4 livres de Alain CHAROY édités sur le sujet chez Dunod. Ils sont très bien faits.

Stop ou encore, dis-tu?
Ben, moi ça fait longtemps que j'ai dit "stop", mais tu sembles insister.

Donc, je dis définitivement "stop".
Si tu repostes, je te déclare vainqueur par forfait, LOL

Sans rancune, c'était une discussion intéressante et sans animosité de ma part. On ne pas être toujours d'accord.

A+
Bigonoff



Numéro de l'article: 59756   |  De: Bigonoff   |  Date: 2003-12-01 23:56:31
   RE: Liaison série bi directionnelle

Encore..On y est presque
Maitrise du mode commun....
"Sur un électrocardiographe, le ou les fils de références servent à annuler la tension parasite issue principalement du rayonnement secteur. C'est logique car le patient est soumis à une ddp à 50Hz superposée au signal utile. Il faut donc une astuce pour soustraire ce signal. Cette astuce est une symétrisation de la liaison."
L'astuce: c'est ca la maitrise du mode commun....
Debranche le 3 ieme fils et alarme du monitoring...
(c'est vrai on fournit une tension de mode commun symetrisant les signaux.)
Meme sans le secteur, le frottement, les ions suffit a creer une ddp (tension) entre le patient(sa masse) et la masse de l'electro.
Y a pas que le patient, tout est soumis aux rayonnement secteur!!
Et plus encore pour le materiel relie au secteur.
cqfd: ----Une mesure en differentielle s'effectue en 3 fils.----


Avec une led, un transfos: valeur eleve possible (jusqu'au claquage)...
"Tu ne peux pas non plus additionner deux tensions qui n'ont pas de référentiel commun."
faux en serie, VE= VM+VS, dit flottant, des qu'une liaison electrique existe on peut, le patient est relie.
Oui: l'interet du differentiel: le parasite qui s'applique sur les deux branches s'annule.
Superpose une tension sur un signal (quand c'est prevu), en telephonie on va jusqu'a 1400 volts
afin de telealimenter les repeteurs entre les centraux.
L'isolation dans les reseaux (CAN, Ethernet, RS485) s'effectue entre le driver et le controleur.
L'alimentation du driver est fourni par le reseau (4 fils), et si elle l'etait par une alimentation
auxiliaire, il faudrait toujours avoir les 3 fils.


Protections et la foudre.
Comme indique plus haut, la masse sert a la maitrise du mode commun, pas a la protection, c'est la terre.
L'opto isolation est une protection passive (Watt=0), 1000V. Exemple: Mise au secteur d'un bus.
Elle est active (eclateur, tansil..) quand il y a de la puissance dissipe, c'est plus dangeureux (risque de feux).On absorbe et/ou on renvoie l'onde.
Il est faux de dire qu'en mettant des protections aux extremite d'un reseau on le protege.
On protege uniquement les deux points. En effet si une onde arrive, elle peut passer et detruire les recepteurs avant d'atteindre la protection. En fait la protection diminue plus on s'eloigne de ceux ci.
On doit en mettre sur toutes les stations. Donc un reseau protege sera constitue pour toutes les stations d'un isolement opto et d'eclateurs a la terre (tresse). C'est lourd. D'ou la segmentation avec des zones "pas protege" (une piece/ une zone par exemple) independante, et des passerelles 'opto-eclateurs'.

Quand on fait un reseau, autant bien savoir le pourquoi des choses.

Convaincu?.

A+
XF


Numéro de l'article: 59883   |  De: XF   |  Date: 2003-12-02 19:03:28
   RE: Liaison série bi directionnelle
Salut
------

J'ai dit "stop". Je ne vais pas tout le temps répéter la même chose.

Lis les livres d'Alain Charoy, tu comprendras ce qu'est le mode commun... et ce qu'est une ddp
Du même coup, tu apprendras la différence entre terre et masse
En même temps, un petit rappel de la loi de Kirchoff te remémorera de la loi des noeuds et des mailles.

Ah oui, pour finir, ne me fais pas dire ce que je n'ai pas dit, je n'ai pas parlé de protections aux 2 bouts, LOL (relis correctement).

Fais ton réseau en ce que tu veux à ton idée, moi je fais le mien en CAN à la mienne. Attendons le résultat final, et attendons la foudre, LOL.

A+
Bigonoff




Numéro de l'article: 60075   |  De: Bigonoff   |  Date: 2003-12-03 23:01:04
   RE: Liaison série bi directionnelle
Bonjour,
A livre... bien qu'une demonstration simple soit suffisante extrait
"PLAGE DE MODE COMMUN.

Dans tous les montages différentiels, il faudra prendre garde à un paramètre : la plage de mode commun admissible par les composants.

Un ampli d'instrumentation est composé d'amplificateurs opérationnels alimentés par des tensions continues. La tension d'entrée va en général être limitée par les tensions positive et négative d'alimentation.

C'est surtout vrai pour les amplis d'instrumentation dont les entrées sont des entrées d' amplis opérationnels, avec toutes les restrictions que cela impose. Par exemple, il sera hors de question de faire rentrer un signal ayant une tension de mode commun de 20V sur un ampli d'instrumentation alimenté en ±15V.

Pour ces montages, on fera aussi attention aux limites imposées par les tensions de sorties maxi des amplis. Si on reprend l'échelle des potentiels de la figure 11, il faudra veiller à ce que les tensions S1 et S2 restent dans des limites acceptables pour l'ampli : cela implique que la somme des tensions de mode commun et du signal amplifié soit inférieure à la limite de saturation des amplis."

C'es pas plus complique... le 3ieme fils.
A +
XF





Numéro de l'article: 60084   |  De: XF   |  Date: 2003-12-04 00:51:18
   RE: Liaison série bi directionnelle
XF je sais pas dans quel domaine tu as une formation et à quel niveau, mais tu parle beaucoup pour dire des betises. Une tension est une difference de potentiel point à la ligne.
Si tu veux tu peux faire des montages electronique dans lesquels tu ajoute un offset de 100V sur tout les points (masse, alimentation et signal d'entrée) et ça fonctionnera toujours. Une masse est une reference que l'on fixe par convention et qui correspond generalement au potentiel de la terre, mais ce n'est pas une obligation notament dans les systemes embarqués. Mais bon j'ai l'impression que tu connais pas les loi de Kirchoff.loolll

Numéro de l'article: 62933   |  De: Ced   |  Date: 2003-12-24 11:01:48

   pb sur tvc grandin  
bonjour a tlm,
en panne sur un grandin 51mbi 94, je n'ai plus rien a part la led de veille qui reste allumee.je n'ai pas les plan elec du chassis et je ne suis pas arrive a controler les alim.
merci de me donner un coup de main.
@+

Numéro de l'article: 56624   |  De: alf 30   |  Date: 2003-11-08 08:30:41
   RE: pb sur tvc grandin
j'ai pas mal de prob.avec la mienne l'ayant envoyée au sav a l'epoque pour un prob. d'alim 6 mois plus tard le meme effet j'ai pris mon courage a deux mains et hop j'etais obligé de constater divers soudures seches sur plusieurs composants
Amon avis verifie visuellement et je suis sur d'un etonnement de ta part
a plus!!!

Numéro de l'article: 56745   |  De: domi   |  Date: 2003-11-09 14:20:57
   RE: pb sur tvc grandin
salut et merci pour ta reponse,
apres verif. rien du cote soudure et rien constate d'anormal.j'ai essaye de controler les U d'alim mais je ne connait pas le brochage transfo donc si qq'un peu m'aider merci d'avance.
A+

Numéro de l'article: 56810   |  De: alf 30   |  Date: 2003-11-09 21:16:12

   Dualboot Windows  
Salut à tous,
Je sais que c'est un peu hors-sujet comme topic, mais je ne sais pas trop où il y a un forum plus adapté.
J'ai windows 98 se sur mon disque C et windows xp sur mon disque D, et ce sont 2 partitions de mon disque dur. Le problème est que j'aimerais supprimer windows 98 et ne garder que le xp. Alors je pense qu'il faudrait faire passé windows xp vers la première partition (le C) mais je ne sais pas trop comment faire.

Merci d'avance pour vos informations ;)

Numéro de l'article: 56628   |  De: dam   |  Date: 2003-11-08 10:32:06
   RE: Dualboot Windows
Hi,

Je pense a un truke ... je pense que cela devrais marcher

tu fait la commande sous DOS :

FDISK

Puis tu a une option Sélection partition

Tu change tu choisis 2 a la place de 1 ..

Sinon il y a des logiciel qui s'occupe de ca aussi
fait une recherche sur google ou autres

+

Numéro de l'article: 56630   |  De: byte   |  Date: 2003-11-08 10:48:56
   RE: Dualboot Windows
Oki mais ça m'arrangerait de ne pas utiliser un logiciel pour faire ça. Et j'ai déjà eu des problèmes avec fdisk qui ne gère pas fort bien les disques de grande capacité.

Alors d'autres idées :p ?

Numéro de l'article: 56633   |  De: dam   |  Date: 2003-11-08 10:56:14
   RE: Dualboot Windows
vas voir chez bellamyjc.net

super site tres bien fait

le multiboot est sa specialité


Numéro de l'article: 56637   |  De: gregelec   |  Date: 2003-11-08 12:24:34
   RE: Dualboot Windows
RE,


Oki mais ça m'arrangerait de ne pas utiliser un logiciel pour faire ça.

--> Si tu veut pas le faire avec un logiciel tu veut le faire comment ? a la main :)


Et j'ai déjà eu des problèmes avec fdisk qui ne gère pas fort bien les disques de grande capacité.


--> Sorry FDISK gêre trés bien partition , même disque dur de 120GB
si tu a u un problème bhen c une erreur de ta part (manipulation)


@+

Numéro de l'article: 56687   |  De: byte   |  Date: 2003-11-08 21:45:59

   Infos composant ESM740G1  
bonjour je voudrai savoir quel est ce composant c notée dessus ESM 740G1 8610 ???? merci de me repondre
nico

Numéro de l'article: 56636   |  De: nicolas27   |  Date: 2003-11-08 12:20:51
   RE: urgent
Recherche ESM740 avec google

apparement c'est du genre THYRISTOR 300V/3A



Numéro de l'article: 56642   |  De: Jean-Louis S.   |  Date: 2003-11-08 12:44:10
   RE: urgent
Salut, c'est effectivement un thyristor qui est en autre monté sur les chassis icc5. Attention on n'en trouve plus beaucoup !

Numéro de l'article: 57067   |  De: boblaiponge   |  Date: 2003-11-11 22:41:08

   Theoreme de Gauss  
bonjour , je suis en iut hse et mon prof d'elec m'a parle du theoreme de Gauss en electrostatique , toutefois je n'ai rien compris au systeme de symetrie des charges ponctuelles ainsi que au petites surfaces que l'on utilise pour l'integrale double... si qqun a vu ca et pourrait m'expliquer succintement ou me diriger vers de s sites je vous en remercirait bcp! merci d'avance

cedric

Numéro de l'article: 56638   |  De: cedric   |  Date: 2003-11-08 12:29:45
   RE: Theoreme de Gauss
Salut,

Un site (en anglais) où il y a tout et qui devrait t'aider:
http://hyperphysics.phy-astr.gsu.edu/hbase/hframe.html

A voir absolument

See you

Numéro de l'article: 56654   |  De: Patman   |  Date: 2003-11-08 15:36:15

   contact tournant !!!!  
bonjour a tous,
voila nous avons besoins de faire passer du courant d une partie fixe a une patrie en rotation.
nous avons appris que l on pouvait faire cela grasse un disque et des patains qui viennes frotter sur des pistes electrique.
si vous avez plus d info sur le sujet merci de me les faire parvenir!

Numéro de l'article: 56639   |  De: jerome   |  Date: 2003-11-08 12:30:21
   RE: contact tournant !!!!
salut

tu peux recupérer les balais et la piste en cuivre du rotor d'un moteur électrique.



Numéro de l'article: 56641   |  De: petitours   |  Date: 2003-11-08 12:42:48
   RE: contact tournant !!!!
ok mai komment fixe nos patins sans empeche la rotation de notre dise ??
et connait tu le basic 11 ??
merci

Numéro de l'article: 56649   |  De: jerome   |  Date: 2003-11-08 14:31:50
   RE: contact tournant !!!!
regarde comment et fait un moteur electrique muni de ces contacts (tous ceux qui ont un rotor avec un bobinage)...
pour le basic 11, si tu as une question précise, refais un post avec un titre qui va bien

Numéro de l'article: 56651   |  De: petitours   |  Date: 2003-11-08 15:13:37
   RE: contact tournant !!!!
je me demande si ce systeme va pa creer denorme parasites....

Numéro de l'article: 56655   |  De: Bandit972   |  Date: 2003-11-08 15:36:16
   RE: contact tournant !!!!
Avec un alternateur de récup, ce serait mieux.

Numéro de l'article: 56659   |  De: André   |  Date: 2003-11-08 16:02:48
   RE: contact tournant !!!!
Tu peux utiliser aussi les "patins" qu'il y a sur les voitures de circuit 24, c exactement le meme principe, apres pour supprimer les parasites.... Les condensateurs, servent justement à cela... ;o)

Numéro de l'article: 58959   |  De: pazcal   |  Date: 2003-11-25 15:16:03

   Réparation cordon Ecran de PC  
Salut,

J'ai un ecran de PC avec la fiche sub-d15 défectueuse. J'aimerai ressouder la fiche mais je ne sais pas comment repérer les couleurs des fils du cordon.
Si qqun pouvait m'aider ce serai sympa.
Merci
@+
Sylvio

Numéro de l'article: 56640   |  De: Sylvio   |  Date: 2003-11-08 12:37:11
   RE: Réparation cordon Ecran de PC
Salut

test avec un autre câble si celui ci est trop endommagé sinon tu trouvera le branchement sur http://www.hwb.acc.umu.se/

@+++ dan

Numéro de l'article: 56691   |  De: dan   |  Date: 2003-11-08 21:53:54

   prise allume cigare 12V==>5V  
salut,
je vien de faire l'aquisition d'un lecteur MP3&DivX avec une baterie integrée. le transfo secteur était livré avec mais moi j'aimerai surtout pouvoir m'en servir dans ma voiture. j'aimerai créer un adapteur 12V pour cet engin.
voici les reference de l'adaptateur secteur:
-Input 100~240 Vac 60/50Hz 0.4A
-Output:+5Vdc _____
----- 1.6A
voila c'est tout ce que je sait donc si vous avez un schema ,un lien ect je vous en remerci d'avance!

Numéro de l'article: 56643   |  De: electro   |  Date: 2003-11-08 12:55:40
   RE: prise allume cigare 12V==>5V
Salut

contacte moi pour que je te fasse un montage ...

@+++ dan

Numéro de l'article: 56689   |  De: dan   |  Date: 2003-11-08 21:49:21
   RE: prise allume cigare 12V==>5V
Bonjour

Il te suffit d'utiliser un 7805 monté sur un petit refroidisseur avec une r de 6.8 en série

voir schéma

A bientôt
###Graphgr_553###

Numéro de l'article: 56692   |  De: EPERVIER   |  Date: 2003-11-08 21:54:51
   RE: prise allume cigare 12V==>5V
merci pour ta reponse je vais essayer ca . par contre est ce que mon lecteur MP3 risquera quelque chose?

Numéro de l'article: 56736   |  De: electro   |  Date: 2003-11-09 12:33:47
   RE: prise allume cigare 12V==>5V
Salut,
une question dans la question ;-)
A quoi servent les condos dans ce montage (j'y connais rien LOL) ?

merci !

Numéro de l'article: 56747   |  De: Niko   |  Date: 2003-11-09 15:38:28
   RE: prise allume cigare 12V==>5V
Bonjour

Ceal marche sans condensateurs mais ceux ci sont recommandés pour avoir un bon découplage et eviter les oscillations (toutefois rares et peu probables mais vaut mieux prévenir que guérir.

Si tu veux encore mieux protéger ton système : places une diode zéner de 5V6 2 w en // sur la sortie et ainsi qu'un fusible de 0.5 A dans l'entrée.

A bientôt

Numéro de l'article: 56778   |  De: EPERVIER   |  Date: 2003-11-09 18:44:17
   RE: prise allume cigare 12V==>5V
Merci pour l'info Epervier ;-)

Numéro de l'article: 56851   |  De: Niko   |  Date: 2003-11-10 10:10:40

   carte DSP  
Bonjour à tous , j'aimerais savoir si quelqu'un sur ce forum a déjà utilisé une carte DSP genre C5402 ou C6207 car j'aurais aimé avoir quelques informations sur ce type de carte . Ou sinon si quelqu'un connait une adresse internet où tout cela est bien expliqué , qu'il me la donne ca serait cool . Si possible je voudrais autre chose que de la doc de chez texas instrument . Merci

Numéro de l'article: 56644   |  De: Steph   |  Date: 2003-11-08 13:13:11

   blaupunkt rcm 82  
salut comment debloquer ce vieux postes sans la key card ?
kelkun aurait le manuel pour les connectiques ?
http://cxema.ru/audio.htm la y a le pdf mais je comprend pas trop car schema elec...
merci de votre aide

Numéro de l'article: 56645   |  De: chaos57   |  Date: 2003-11-08 13:53:09
   Blaupunkt Type PM 40-41 F
J'ai aussi un problème de clé.
Sur mon téléviseur qui fonctionne avec une télécommande universelle
Wallis 601, à l'écran s'affichent 4 clés et un code à rentrer (4 chiffres entre 0-9)
Or n'ai jamais verrouillé mon poste.
HELP ME PLEASE
MERCI



Numéro de l'article: 60101   |  De: COSSARD   |  Date: 2003-12-04 11:25:24

   commande brsuhless par pic  
Bonjour,

il faut pour une application que je commande un moteur brushless avec un pic 18f458.

je n'ai encore jamais utilisé de brushless donc si vous avez des infos, des composants qui vont bien, je suis perneur.

de plus j'ai lu que la commande en sensorless (c'est mon cas) n'est pas très conseiller lorsqu'il y a des changements rapide de la charge (ce qui est aussi mon cas). le probleme c'est que je n'ai trouvé que des moteurs pour modelisme sensorless qui conviennent pour mon application et mon porte-monnaie.

j'attend votre aide.
MErci d'avance.

A+
Nico

Numéro de l'article: 56647   |  De: nico26   |  Date: 2003-11-08 14:16:30
   RE: commande brsuhless par pic
Bonjour,

Pour le principe de pilotage regarde sur le site de ST.
Les datasheet expliquent assez bien le fonctionnement en mode sensorless.

En deux mots voila ce qu'il faut faire sur le PIC :

- le principe de commande est un séquenceur à 6 états avec pour chaque état 1 sortie à 1, 1 sortie à 0 et une broche en entrée pour la mesure de la BEMF (mesure de la force contre-éléctromotrice qui remplace les capteurs en mode sensorless)

- une première séquence de démarrage pour accrocher la bonne phase (on ne connait pas la position du rotor au départ) en passant d'une phase à l'autre en vitesse lente jusqu'à mesurer la BEMF correctement

- ensuite le programme bascule en séquence normal en continuant l'ordre des phases.

Pour la régulation de vitesse, il faut inclure un PWM sur la sortie à 1 ou de manière général sur l'alimentation du pont triphasé.

C'est pas évident, mais ça se fait !!!

Cdt

Thierry



Numéro de l'article: 56876   |  De: Thierry Subtil   |  Date: 2003-11-10 13:19:46
   RE: commande brsuhless par pic
Salut Thierry,

merci pour ta réponse, mais j'en ai une autre,

les fabricants de modelisme vendent des controleur tout fait. penses-tu qu'il sont performant lorsqu'il y a des changements de couple rapide et le sont ils plus que si je fais mon controleur avec un pic?

Merci d'avance

A+
Nicolas

Numéro de l'article: 56997   |  De: nico26   |  Date: 2003-11-11 14:12:50
   RE: commande brsuhless par pic
Bonjour,

Pour ce qui est des contoleurs brushless pour modélisme, j'en ai acheté un il y a quelques mois chez NPM mais je n'ai pas encore pris le temps de le tester. En fait je voulais éssayer la commande d'un moteur de CD-ROM pour un avion, j'ai tout le matos mais il manque l'essentiel : le temps !!!
Par contre je ne savais pas qu'il y avait des différences de performances avec ou sans capteur.D'ou tiens-tu l'info ?

Cdt

Thierry

Numéro de l'article: 57045   |  De: Thierry SUBTIL   |  Date: 2003-11-11 19:54:41
   RE: commande brsuhless par pic
Salut,

je tiens l'info d'une note d'appli de chez microchip. cherche brushless sur leur site.

as-tu une adresse internet pour NPM et combien as tu payer ton controleur, si c'est pas indiscret. fait il les des sens ou fait il juste la marche avant?

A+
Nicolas

Numéro de l'article: 57052   |  De: nico26   |  Date: 2003-11-11 21:10:25
   RE: commande brsuhless par pic
Bonjour,

En plus je dois l'avoir cette note d'appli vu que c'est mon job la commande de moteur!!!
NPM c'est NEW POWER MODELISME (recherche du site par google) et le controleur coute environ 60 euros et je pense qu'il n'a qu'un sens vu la destination du produit.

Merci

Cdt

Thierry

Numéro de l'article: 57121   |  De: Thierry Subtil   |  Date: 2003-11-12 13:34:58
   RE: commande brsuhless par pic
Salut,

c'est vrai, c'est ton job la commande de moteur. Moi ca fait parti du mien, mais j'ai encore jamais joué avec les brushless. je suis prenuer de toutes les infos.

A+
Nico

Numéro de l'article: 57191   |  De: nico26   |  Date: 2003-11-12 21:09:08
   RE: commande brsuhless par pic
salut thierry,

par rapport a la presence des capteurs ou non j'ai quelques pricisions a te demander:

la commande avec capteur est plus facile par contre ils sont plus cher, c'est ca,
combien de temps la sequence de demmarrege en sensorless pour accrocher la bonne phase dure combien de temps car mon moteur fonctionnera par intermittance pendant 50ms. j'ai peur que cela soit trop juste pour le sensorless?
a taille comparable lequel des 2 aura le plus de puissance (surtout au niveau du couple)?

Merci et a plus

Nico

Numéro de l'article: 57908   |  De: nico26   |  Date: 2003-11-17 20:56:59

   trouver des pièces détachées  
bonjour.
j'aurais besoin d'un tripleur 30 KV de tele mais je ne sais pas ou le demander ; à votre avis est ce que DARTY vend des pièces détachées
d'appareils (pas l'appareil en entier) ?
et si non quels sont les magasins suceptibles de m'en vendre ou de m'en passer gratuitement d'occasion ?
je vous remercie.

Numéro de l'article: 56650   |  De: nani ?! nysho nande ?   |  Date: 2003-11-08 15:10:12
   RE: trouver des pièces détachées
je suis allé à darty et nada ; il me reste plus qu'à trouver un dépanneur TV mais il n'existe vraiment pas de magasin qui me passerait un tripleur gratis ?

Numéro de l'article: 56662   |  De: nani ?! nysho nande ?   |  Date: 2003-11-08 16:15:29

   Liaison SPI avec LCD  
Je cherche depuis quelque temps comment communiquer avec un LCD ayant comme controleur un SSD1801.. J'ai fait quelques essais avec le port // d'un PC mais rien de concluant^..
Est-ce que qqun peut m'aider ?
Merci d'avance

Xwave
admin (AT) xwaves POINT net

Numéro de l'article: 56653   |  De: Xwave   |  Date: 2003-11-08 15:26:33
   RE: Liaison SPI avec LCD
Envoi moi pas mail ton programme ou au moins ce que tu envoi à ton afficheur. Je vais scanner la doc des afficheurs demain.

Olivier

Numéro de l'article: 56699   |  De: gemiolac   |  Date: 2003-11-08 22:10:14

   démodulation FM  
Bonjour,

En regardant certain montage de démodulation FM, je me suis aperçu que certain démodulait le signal avec un quartz 10.7MHz et d'autres avec une fréquence 455 KHz
Quel est la meilleur fréquence pour démoduler et pourquoi passer de 10.7 MHz à 455 MHz ??

Merci

Numéro de l'article: 56656   |  De: Ano   |  Date: 2003-11-08 15:39:13
   RE: démodulation FM
Bonjour,
Tout dépend de l'usage auquel est destiné le récepteur. Pour la FM classique (87/108 Mhz) une FI en 10.7 Mhz est suffisante par contre, s'il s'agit d'un récepteur destiné à l'écoute radioamateur, une FI de 455 Khz s'impose.

Numéro de l'article: 56660   |  De: André   |  Date: 2003-11-08 16:09:33
   RE: démodulation FM
Salut

- La démodulation FM à 10,7 MHz est dite large bande; elle correspond à des transmissions audio de qualité ou de données rapides (< 100 kbps). Typiquement la radiodiffusion FM stéréophonique où l'excursion de fréquence est de 75 kHz nécessaire pour la qualité audio au détriment de la sensibilité du récepteur.
- La démodulation FM à 455 kHz est dite bande étroite; elle correspond à des transmissions ou la sensibilité (donc la portée) prime. Typiquement les talkie walkies type PMR où l'excursion de fréquence est de 1,5 à 3 kHz; la qualité audio est alors très réduite (idem téléphone).

A+

Numéro de l'article: 56674   |  De: SuperPapum   |  Date: 2003-11-08 18:53:40

   aide urgente branchement d'une rampe PAR 36  
Quelqu'un pourrai t'il me renseigner sur le branchement de par 36 en faite comment doige faire pour brancher avec le moins de fil possible une ramp de trois spot par 36 qui devrais se connecter sur un chenillard merci en atende de votre reponse
Roland tres urgent


Numéro de l'article: 56657   |  De: Roland   |  Date: 2003-11-08 15:39:36
   RE: aide urgente branchement d'une rampe PAR 36
Bonjours, il vous faut connecter vos lampes en parallèle, voir le schéma ci joint.

Remarque, le fil reliant le chenillard à la première lampe doit avoir une section + importante, car le courant véhiculé est plus grand.
Cliquez ici pour ouvrir l'image


Numéro de l'article: 56663   |  De: Régis   |  Date: 2003-11-08 16:35:22
   RE: aide urgente branchement d'une rampe PAR 36
je te remercie pour ta reponse mais je me suis peut etre mal exprimer
en fait se n'est pas en paralèle que je voudrai les mettre mais en serie c'est a dire un par 36 indépandant donc un apres l'autre en somme c'est pour eviter d'avoir trois ralonge de +- 4 mettre entre les par 36 et le chenillard qui lui sera a +- 4 m de distance si tu voit ce que je veut dire
merci

Numéro de l'article: 56728   |  De: Roland   |  Date: 2003-11-09 11:18:20
   RE: aide urgente branchement d'une rampe PAR 36
slt
ce que tu peux faire c de tirer une rallonge en multipaires de 6 fils donc 3 paires je m'explique:
tu auras un neutre commun a chaque projecteur et une terre commune seule les phase resterons individuelles.
n'oublie pas le probleme important des par 36 c'est qu'ils sont alimenter en TBT c'est a dire par un transformateur abaisseur donc pas trop super pour les eteindre ou les allumer tout le temps ou a condition que ton chenillard soit prévu pour (sinon tu va cramer tes fusible ou et ton transfo va vibrer)
Sinon si tu debute dans la sono je te conseille directement les par 56 c'est vrai c un peu chere par rapport au par 36 mais le resultat est la !
voila voila un jeune vieux des festivales lol

PS: autre solution les par 64 mais la attention a ton alim ...

Numéro de l'article: 56737   |  De: alexclement17   |  Date: 2003-11-09 12:36:14
   RE: aide urgente branchement d'une rampe PAR 36
quel chenillard me conseil tu pour ce genre de projecteur en par 36 j'en ai optenu 6 gratos
merci a toi


Numéro de l'article: 56743   |  De: Roland   |  Date: 2003-11-09 14:03:24
   RE: aide urgente branchement d'une rampe PAR 36
quel chenillard me conseil tu pour ce genre de projecteur en par 36 j'en ai optenu 6 gratos
merci a toi


Numéro de l'article: 56758   |  De: Roland   |  Date: 2003-11-09 17:25:58
   RE: aide urgente branchement d'une rampe PAR 36
N'importe quel chenillard fera l'affaire.Le rs 40 ou le lm400 de jbsysteme par exemple.(tant qu'il peut commander des charges inductives car les par36 ont un transfo intégré)

FABRICE

Numéro de l'article: 56794   |  De: FABRICE   |  Date: 2003-11-09 20:23:51
   RE: aide urgente branchement d'une rampe PAR 36
merci beaucoup fabrice


Numéro de l'article: 56799   |  De: Roland   |  Date: 2003-11-09 20:35:29
   RE: aide urgente branchement d'une rampe PAR 36
pour info: le lm400 tient ses 3kw répartis en charges rés. il tient également en cas de charges indusctive, mais pour une charge plus faible (pas plus de 3/4 par36 par canaux)

Numéro de l'article: 57039   |  De: impson   |  Date: 2003-11-11 19:13:03

   module aurel  
Bonjour,
J aurais aimer avoir des informations concernant la conception des modules d'emission et de transmission aurel fonctionnant a haute frequence. Dans le carde d un micro sans fil, j aurais aimer le realiser moi meme( comprendre son fonctionement..) car c'est plus ludique de le faire que d'en prendre un tout fait.
Si vous avez des explications, des shemas, tout..je suis preneur.
Cordialement
Christophe

Numéro de l'article: 56658   |  De: chris   |  Date: 2003-11-08 15:59:48

   testeur de pile  
bonjour à tous, je suis en 1ère S option Si et je cherche des infos, sites, schémas électrique sur des testeurs de piles à affichage Lcd pour mon tpe.Merci

Numéro de l'article: 56661   |  De: lalane89   |  Date: 2003-11-08 16:14:10
   RE: testeur de pile
tu veux le faire avec un PIC ? un microcontroleur ?

Olivier

Numéro de l'article: 56696   |  De: gemiolac   |  Date: 2003-11-08 22:08:14
   RE: testeur de pile
tu veux utiliser un 7106? dans ce cas la tu peux trouver un schéma tout fait sur la datasheet (je peux te la fournir si tu veux)
@++



Numéro de l'article: 56746   |  De: manu   |  Date: 2003-11-09 15:08:35
   RE: testeur de pile
Non je veux juste des info pour fabriquer un testeur de piles, peu importe qu'il y ait un PIC ou un microcontroleur.

Numéro de l'article: 57208   |  De: lalane89   |  Date: 2003-11-12 21:50:04
   RE: testeur de pile
Manu peux tu me passer le schémas dont tu parles ds le datasheet?

Numéro de l'article: 57292   |  De: lalane89   |  Date: 2003-11-13 16:54:14

   compilo C18  
Bonjour,

J'ai installé la version demo de C18 en debut d'apres-midi. Je sais qu'il est limité à 30 jours mais il vient de me faire l'erreur suivante :
Demo version time limit expired.

d'où cela vient-il?

Merci pour vos réponses.

A+
Nico

Numéro de l'article: 56664   |  De: nico26   |  Date: 2003-11-08 17:10:12
   RE: compilo C18
Recherche ce que tu as modifier sur ton pc (ajout supp de programme, modification d'heure, ménage ...)
Une cle de registre a été modifiée ou supprimée.

Olivier

Numéro de l'article: 56695   |  De: gemiolac   |  Date: 2003-11-08 22:07:31
   RE: compilo C18
Salut,

merci pour la réponse,

j'avais modifié le jour de mon pc qui n'était pas le bon.

A+
Nico

Numéro de l'article: 56748   |  De: nico26   |  Date: 2003-11-09 15:41:06

   ajouter une sortie audio  
Bonjour,

J'ai besoin d'une 2éme sortie audio sur ma carte son pour alimenter un petit emetteur TV (home made sur le canal 36). Quelle est la meilleure façon d'ajouter une sortie audio à ma carte son ? (Je suppose que la mise en // n'est pas la meilleure !)

Merci

PS: je cherche aussi des infos sur le codage NICAM, alors si vous avez des liens sympa....
Harry

Numéro de l'article: 56666   |  De: harry   |  Date: 2003-11-08 17:43:18
   RE: ajouter une sortie audio
Salut

La mise en // est la solution la plus simple sans aucune dégradation audio. Attention, si ta carte est déja directement reliée à des HP tu risques d'avoir des soucis de différence de volume (son fort / Emetteur TV si son OK / HP ou son faible /Emetteur TV si son Ok / HP) Mettre un ampli dédié aux HP est la meilleure solution, à moins que tu utilises des enceintes actives. Il reste très simple d'essayer. Aucun risque de casse !
A+

Numéro de l'article: 56673   |  De: SuperPapum   |  Date: 2003-11-08 18:46:05

   Basic 11  
j aurai aime savoir si quelqu un connait un site ou l on peut apprendre a manipulé le basic 11
merci

Numéro de l'article: 56667   |  De: jerome   |  Date: 2003-11-08 17:57:28

   achete doc Toshiba V761F  
achete doc technique vhs toshiba v761f.
merci

Numéro de l'article: 56668   |  De: dom   |  Date: 2003-11-08 17:58:48

   televiseur brandt  
bonjour, j'ai un televiseur brandt. j'ai un bande noir en bas de l'ecran avc une image tasser en haut de l'ecran. si quelqun peut m'aider a la reparer ce serai cool

Numéro de l'article: 56669   |  De: nicolas27   |  Date: 2003-11-08 18:21:55
   RE: televiseur brandt
Indique aussi le modèle du TV.
Mais c'est certainement un classique condo qui est sec dans l'ampli vertical.

Numéro de l'article: 56706   |  De: Fas54   |  Date: 2003-11-08 23:16:00
   RE: televiseur brandt
le chassis est un ICC5
ok pour le condo mais je comme je connait pas trop je sais pas ou se trouve l'ampli vertical? il y a koi autour du condo ???

Numéro de l'article: 56710   |  De: nicolas27   |  Date: 2003-11-09 00:03:42
   RE: televiseur brandt
Salut, sur ce chassis,il y a les potentiomètres de réglage de géométrie qui s' oxydent(se trouvent sur le plastique marron),tourne plusieur fois celui qui a les deux flèches(une qui monte et l' autre qui descend) et ton problème sera résolu.
A+

Numéro de l'article: 56713   |  De: davtech   |  Date: 2003-11-09 09:44:09

   [Technics]Tuner ne pilote plus l'ampli  
Bonjour,
Mon tuner Technics ST-X999L ne pilote plus la mise en marche de l'ampli (SU-X999) et donc le reste de l'installation.
La sortie AC Outlet du Tuner est OK - tension en permanence -> normal ?.
Si je branche la prise de courant de l'ampli directement sur le secteur il fonctionne, mais chaque élément de la chaîne doit être enclenché séparément.

Serait-ce la sortie "Control Amplifier" du tuner qui pose problème ou l'entrée "Tuner Control" de l'ampli ?
Comment controler cela ?

Merci pour vos conseils

Horst

Numéro de l'article: 56670   |  De: Horst   |  Date: 2003-11-08 18:22:23

   sono  
blr je cherche quelqu'un qui aurrai msn messenger ey qui soit connesseur dans la sonorisation de voiture pour en apprendre un peux sur ce sujet.merci

Numéro de l'article: 56671   |  De: kevin   |  Date: 2003-11-08 18:26:50
   RE: sono
mon adresse msn est bricedenice8887@msn.com je vous remerci de prendre contact avec moi.kevin

Numéro de l'article: 56672   |  De: kevin   |  Date: 2003-11-08 18:29:29
   RE: sono
Salut;

Que désires-tu savoir ? ...

Je pense que se serait bien de poser tes questions sur le forum, ainsi tous le monde poura participé et sa apprendra a tous...



CiAo...

Numéro de l'article: 56684   |  De: Tronic-man   |  Date: 2003-11-08 21:22:15

   comment déphaser une onde ?  
bonsoir.
comment faut il faire pour déphaser une onde de 180 degrés ?
merci.

Numéro de l'article: 56677   |  De: kenjutsu   |  Date: 2003-11-08 19:03:03
   RE: comment déphaser une onde ?
Salut

1 - Tu fait un filtre passe bas (par exemple) qui présente donc un point de sa réponse avec 180° de déphasage.
2 - Tu fais un filtre dit "passe tout" afin de faire les 180°:
http://www.filter-solutions.com/passive.html#allpass
http://www.eng.auburn.edu/~wilambm/elec6970/c/class16.pdf
http://www.w3am.com/8poleapf.html
3 - Tu utilises une longueur de cable telle qu'elle provoque un retard de 180°.
Ya pu ka...
A+

Numéro de l'article: 56680   |  De: SuperPapum   |  Date: 2003-11-08 20:27:41
   RE: comment déphaser une onde ?
Bonjours,
1- tout simplement inverser votre signal (AOP inverseur à gain unitaire)
2-vous pouver utiliser deux circuits déphaseur d'ordre 1 en cascade (soit des circuits à bases d'AOP)

Pour vous répondre avec plus de préçision il faudrait préçiser la fréquence de votre signal, le signal est-il pour un circuit de commande ou de puissance.

Cordialement,
Régis


Numéro de l'article: 56682   |  De: Régis   |  Date: 2003-11-08 20:35:53
   RE: comment déphaser une onde ?
merci à vous.
je n'utilise pas de montage particulier,c'est juste pour connaitre le principe du déphasage.
bonne journée.

Numéro de l'article: 56753   |  De: fabrice   |  Date: 2003-11-09 16:47:25

   TV THOMSON 21MS10F  
Salut,
THOSON 21MS10F; pas de image, pas de son, écran noir.
Transistor alim S2000 bon, diodes bon, colect..S2000 150V
Filtre 310V. Tension BU ligne 0V.
Merci de m'aider.

Numéro de l'article: 56679   |  De: joseph   |  Date: 2003-11-08 19:27:20
   RE: télévision
Bonjour

AS-tu essayé avec une lampe de 60 w sur le 145 v en ayant débranché le bu508 ou s2000 (ligne)?

A bientôt


Numéro de l'article: 56690   |  De: EPERVIER   |  Date: 2003-11-08 21:50:04
   RE: télévision
Salut, c' est quoi comme chassis?
Il doit te manqué une alimentation au secondaire, par exemple celle qui sert pour le driver ligne.
A+

Numéro de l'article: 56712   |  De: davtech   |  Date: 2003-11-09 09:39:18
   RE: télévision
Salut;
A la place du fusible,j'ai branché une lampe, elle éclaire fortement
pendant quelques secondes, puis elle s'éteint.
A bientot.

Numéro de l'article: 56715   |  De: joseph   |  Date: 2003-11-09 09:49:17
   RE: télévision
Salut,
Chassis N° je ne sais pas.
A+.

Numéro de l'article: 56716   |  De: joseph   |  Date: 2003-11-09 09:56:40
   RE: télévision
Chez Thomson, il marque toujours la ref du chassis soit sur le capot soit sur le chassis lui même.En principe ça commence par ICC...
A+

Numéro de l'article: 56718   |  De: davtech   |  Date: 2003-11-09 10:17:30
   RE: télévision

c'est tout ce qui est marqué: Type:409/TX91 GF et BK4029691
Fabriqué en Espagne.Pas de CCI
Alors merci quand meme.

Numéro de l'article: 56730   |  De: joseph   |  Date: 2003-11-09 11:25:25
   RE: télévision
chassis tx 91
le transistor ligne en cc
ou le tranfo tht?



Numéro de l'article: 56814   |  De: eric   |  Date: 2003-11-09 21:34:03
   RE: télévision
Bonjour
Regardes dans ta boite aux lettres

A bientôt

Numéro de l'article: 56865   |  De: EPERVIER   |  Date: 2003-11-10 11:42:22

   intensité secondaire  
Bonsoir.
Connaissez vous l'intensité du courant du secondaire d'une bobine d'allumage de voiture ?


Numéro de l'article: 56681   |  De: fabrice   |  Date: 2003-11-08 20:28:19

   Question sur les AMPLIS  
Salut à tous,

Val je dois répondre à ces questions, c'est ce que j'ai fait, mais ... est-ce juste svp ???

Le schéma est à la fin ...
VSAT=15V

1) Mode de fonctionnement de A1, valeurs possibles de V2 ?
--> Mode commutation car pas de rebouclage sur la broche -, valeurs possibles pour V2 (+Vsat si V+>V- et -Vsat si V->V+)

2) Expression littérale de V+ en fonction de V1 et V2
--> J'utilise le théorème de superposition
Donc V+=(V2R1)/(R1+R2) + (V1R2)/(R1+R2)
Donc V+=(V2R1 V1R2)/(R1+R2)

3) A quelle condition sur V+ la sortie de A bascule t'elle ?
Donner l'expression de la tension de seul V1 pour faire basculer V2
--> Il ya basculemement si V+=V- donc si V1=V- donc si V1=0

4) Déterminer l'expression e la tension de seuil (V1') permettant d'avoir un front montant sur la tension V2
Je ne comprends pas du tout la question ???
5) Déterminer l'expression e la tension de seuil (V1'') permettant d'avoir un front descendant sur la tension V2
Idem ???
7) Comment s'appelle ce montage ?
"Tout ou rien ???"

Merci d'avance ...
SCHEMA :


Cliquez ici pour ouvrir l'image


Numéro de l'article: 56688   |  De: The Cyber Lewis   |  Date: 2003-11-08 21:47:48
   RE: Question sur les AMPLIS
3)2) V1=-v2.(R1/R2)

4) V1'=-vsat.(r1/r2)
5) v1''=vsat.(r1/r2)
6) ce montage est un comparateur trigger de schmitt

en esperan ke j ai pu t aider
Alex

Numéro de l'article: 56717   |  De: Alex   |  Date: 2003-11-09 10:08:43
   RE: Question sur les AMPLIS
Oh oui merci bien ...

Numéro de l'article: 56760   |  De: The Cyber Lewis   |  Date: 2003-11-09 17:44:22

   432 MHz ? 868 MHz ? 27 MHz !!!  
Hello tous,
Je voudrais me fabriquer une télecommande maison tout ou rien, 4 ordres à longue portée (100-200m). Bien sur la porteuse sur 432 ou 868 MHz est dans l'air du temps. Mais pourquoi pas sur 27 MHz tout simplement ? 27 MHz permet une plus longue portée et c'est plus facile de fabriquer un oscillateur. Qu'en pensez-vous ?

Numéro de l'article: 56698   |  De: Bosseur   |  Date: 2003-11-08 22:09:40
   RE: 432 MHz ? 868 MHz ? 27 MHz !!!
Salut

Hélas le 27 MHz ne permet de portée plus grande qu'à partir du moment où tu arrives à le rayonner correctement... ce qui suppose une antenne de 2.50 m sur ta téléco !!! Dés que l'on réduit la taille d'antenne, la puissance rayonnée s'effondre et la portée devient ridicule. Reste en 434 ou 868, tu seras moins déçu !

A+

Numéro de l'article: 56724   |  De: SuperPapum   |  Date: 2003-11-09 10:51:39
   RE: 432 MHz ? 868 MHz ? 27 MHz !!!
Oui, c'est vrai... Maintenant le 400MHz portera un peu plus loin que le 800MHz
harry

Numéro de l'article: 56731   |  De: harry   |  Date: 2003-11-09 11:28:26
   RE: 432 MHz ? 868 MHz ? 27 MHz !!!
Salut

Et non ! Vu d'une téléco, le 868 et le 434, c'est pareil. En effet si en théorie le 434 présente moins de pertes de transmission, le 868 permet de faire des antennes miniatures de rendement plus élevé...
A+

Numéro de l'article: 56769   |  De: SuperPapum   |  Date: 2003-11-09 18:11:04
   RE: 432 MHz ? 868 MHz ? 27 MHz !!!
Merci

Numéro de l'article: 56930   |  De: Bosseur   |  Date: 2003-11-10 20:35:31