Show Posts
Pages: 1 ... 102 103 [104] 105 106 ... 238
1546  International / Français / Re: [Mise sur rails] Laser distance + Arduino UNO on: August 23, 2013, 09:56:07 am
Quote
Après bon, si tu perçois mes messages comme des jérémiades rien ne t'oblige à répondre smiley-wink Je suis juste un noob en élec qui à un projet à livrer la semaine prochaine.
C'est pas ce que je dis.
Je dis qu'on ne se plaint pas d'une mesure bruitée si on a un câblage bordélique (c'est toi qui le dit pas moi).

Maintenant concernant ta mesure. Le voltmètre intègre la mesure sur une période de temps relativement importante pour que la lecture soit plus facile, donc il ne faut pas s'étonner de voir des fluctuations coté Arduino.
Maintenant tu trouves une fluctuation de -20mV à +60mV soit +/-40mV environ.
D'après la notice du capteur, en mode rapide la précision de répétabilité est de +/-10mm et en lent de +/-5mm.
Si tu as programmé une amplitude de mesure de 1m une erreur de 10mm c'est 1/100. L'amplitude du signal à l'entrée de l'arduino c'est 5V (pour 1m) donc une erreur de 1/100 cela fait 50mV.
Donc les fluctuations de ta mesure sont dans les spécifications (si tu es en mode rapide, mais tu n'as pas précisé si tu es en mode rapide ou lent).
1547  International / Français / Re: Requête get et this. sur arduino on: August 23, 2013, 07:20:15 am
J'avais fait une réponse ce matin qui c'est perdue bizarre.
Je disais que tu ferais mieux de créer une classe dérivée qui hérite de OneWire. Ainsi les objets créés posséderaient toutes les méthodes de OneWire auxquelles s'ajouteraient les getters et les setters ainsi que les propriétés (name par exemple) que tu veux ajouter.
1548  International / Français / Re: [Mise sur rails] Laser distance + Arduino UNO on: August 23, 2013, 07:12:33 am
Quote
Reste un dernier souci maintenant. Ce fameux voltage que je reçois oscille beaucoup trop, il n'est pas stable.
Il faut être factuel. Donne des valeurs.
La doc du capteur donne +/- 10mm en mode rapide et +/-5mm en mode lent.
A quelle distance es-tu et de combien la mesure varie-t-elle?

Quote
l'état actuel des connections est pas mal bordélique !
Donc déjà, avant de se plaindre d'un mauvais fonctionnement on met toutes les chances de son coté.
1549  International / Français / Re: vider une chaine de caractère on: August 23, 2013, 07:07:25 am
flush() attend que le buffer d'émission soit vide.

Pour vider le buffer de réception il faut faire:

Code:
while (Serial.available()){
    Serial.read();
}

Le problème de ton code c'est que tu ne synchronise pas la réception sur le caractère de début de trame (0x01). Du coup, si tu te décales, tu es perdu et tu ne raccroches jamais  correctement sur ton message.
Pour vider une chaîne il suffit de mettre NULL ( ou 0) dans le premier élément, c'est le terminateur de chaîne.

Il n'y a ps de raisons pour que le buffer sature. Tes chaînes arrivent à quelle vitesse?
1550  International / Français / Re: convertir un float en string, avec formatage on: August 23, 2013, 06:56:17 am
Quote
Afin d'effectuer la mesure avec un arduino, j'utilise la broche de celui-ci, sur laquelle je colle une interruption.
a chaque interruption, donc chaque désintégration, j'appelle une fonction qui vas incrémenter une valeur. au bout de 60 seconde cet valeur sera le CPM.

Ce serait plus malin d'utiliser un timer pour faire ça. Cela ne consomme pas de temps sauf au moment du débordement.
Voir là une bibliothèque qui peut être utilisée telle quelle ou adaptée si besoin: http://interface.khm.de/index.php/lab/experiments/arduino-frequency-counter-library/
1551  International / Français / Re: Requête get et this. sur arduino on: August 22, 2013, 02:58:12 pm
Voir là l'utilisation de this http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr035.htm
ou là:http://www.siteduzero.com/informatique/tutoriels/programmez-avec-le-langage-c/le-pointeur-this

Quote
Est ce que le simple fait de déclaré une variable private dans le header ( nomDeLaClass.h) la rend réellement private ?
oui
1552  International / Français / Re: [Projet viable ou pas ?] Autoradio + Instrumentation on: August 21, 2013, 07:24:18 am
Quote
le seul doute que je vais émettre c'est est-ce que l'Atmega sera suffisamment performant pour gérer l'ensemble car tout ce qui écran tactile+affichage risque de consommer pas mal de ressources
Pour mettre les choses en perspective, une image 320x240 met plusieurs secondes pour être chargée par l'ATmega.
Donc graphique lourd et Arduino cela ne fait pas bon ménage.
Il faut soit:
     passer à un processeur plus performant
     utiliser un écran avec un coprocesseur intégré (comme les écrans 4D Systems par exemple)

Gérer un autoradio existant ça parait assez problématique sauf à avoir les informations sur l'interface de celui-ci.
1553  International / Français / Re: [Mise sur rails] Laser distance + Arduino UNO on: August 21, 2013, 04:31:51 am
On a déjà donné toutes les infos possibles. Tout est dans la notice que tu as donnée en lien au début (copie de la partie intéressante ci-dessous).
La notice dit qu'il faut une alimentation entre 18 et 30V. 24V c'est standard on en trouve partout.
La notice dit que le capteur consomme au maximum 125mA sans charge. Donc en fonctionnement il consommera dans les 150mA. Tu prends 200mA minimum pour avoir de la marge.
La notice dit que l'alimentation se connecte:
               le plus sur la broche 1 du connecteur du capteur
               le moins sur la broche 3 du connecteur du capteur c'est aussi la masse du capteur
La notice dit que le signal de sortie est disponible sur la broche 5. Que c'est une source de courant et que le retour du courant se fait par la broche 3 (la masse)

Je ne vois pas ce qui te manque encore
1554  International / Le bar / Re: Bonne affaire (matrices RGB) Ki k'en veut ? on: August 20, 2013, 03:01:24 pm
Une sûre pour moi.
Je me tâte toujours pour la deuxième.
Pour ce prix là c'est criminel d'hésiter smiley-mr-green
Marchand de tapis. smiley-lol

Je viens juste de recevoir une Due que j'avais commandée il y a quelques temps et je me dis que la Due et ces matrices devraient faire qq chose de sympa. Mais bon, j'ai aussi des impératifs budgétaires.... donc j'hésite.
En même temps cela m’embêterait de devenir un grand criminel...
1555  International / Le bar / Re: Bonne affaire (matrices RGB) Ki k'en veut ? on: August 20, 2013, 09:10:49 am
Une sûre pour moi.
Je me tâte toujours pour la deuxième.
1556  International / Français / Re: Nouveau materiel ! on: August 20, 2013, 02:44:44 am
Salut , je compte faire une mini voiture téléguidé via Xbee et ma commande vien d'arriver , voici les explications  :
Partie emettrice : Arduino Uno ou Leonardo + Xbee Shield + Xbee + Manette PS2
Partie receptrice : MBoard  + Xbee + 2 Moteur

Ce que je comprend pas :
1. La MBoard est sorte d'arduino ( http://www.exp-tech.de/Mainboards/Arduino/MBoard-Arduino-with-L298P-motor-driver.html ) , donc elle a les meme pin sauf que dans cella je trouve pas les pin 1 , 2 ,3 ... En plus , dans le code je sais pas quoi metre comme pin pour les sortie moteur (OUT1,2,3 et 4)

2. Quel port serie doit je utiliser dans le code , serial ou serial1 ?

3. J'ai également achété "Foca V2.2 FT232RL Tiny Breakout USB to Serial UART Interface" (http://www.exp-tech.de/Shields/Foca-V2-1-FT232RL-Tiny-Breakout-USB-to-Serial-UART-Interface.html ) , un programmeur d'Xbee via X-CTU , le probléme la c'est que je ne sais pas que voltage mettre car il y'a le 3V et le 5V , et si l'Xbee s'alimente en 3V et que je mais accidentellement 5V elle s'endomagera ?
Moi ce que je ne comprends pas c'est que l'on puisse acheter une carte sans avoir regardé au préalable comment elle fonctionne et s'être assuré qu'elle pourra faire ce que l'on veut avec !
Mais bon...

Pour répondre à tes questions c'est facile regarde dans la bas de la page que tu as mise en lien. Il y a le schéma de la carte et surtout sa datasheet dans laquelle tu trouvera le brochage des connecteurs et l'équivalence du nom des broches entre le monde Arduino et le monde MBoard.

Si l'XBee fonctionne en 3V le mieux c'est peut être de lui donner du 3V tu ne crois pas ?
Et oui si tu mets du 5V tu vas certainement endommager ta carte XBee
1557  International / Français / Re: [Conseil] Pilotage d'un réseau de trains miniatures on: August 20, 2013, 02:27:38 am
Bonsoir,

Merci à fdufnews pour cette réponse. Elle me plaît bien, je souhaitais et j'espérais un peu une réponse dans ce sens, mettre un carte Arduino par bloc est intéressante et souple et cela ne me pose pas de problèmes.
Quote from: fdufnews
Les blocs sont ainsi indépendants les uns des autres. Le code peut être commun par contre.
Est-ce que cela veut dire qu'il doit y avoir obligatoirement un carte maître pour que le code soit commun ou le même code est chargé dans chaque carte?

Pour que le code soit commun il faut que tout les blocs aient le même comportement. Ou du moins que la logique de gestion des blocs soit la même pour tout les blocs.
Après s'il y a des exceptions on peut toujours imaginer des paramètres en EEPROM qui activent/désactivent des options du logiciel.
L’intérêt d'avoir un logiciel commun c'est de ne faire qu'un développement et qu'une mise au point.

Mon idée étant plutôt ce que tu expliques ici :
Quote
Sans maitre
   - un bus RS485 multi-maitres les cartes parlant à tour de rôle avec leurs voisines et s'autogérant.  Le système n'ayant pas de maitre est normalement plus fiable mais le problème des carambolages sur le bus peut être pénalisant avec de nombreux acteurs sur le bus.
   - le RX d'une carte sur le TX de sa voisine et ainsi de suite pour faire une espèce de daisy-chain. Sans doute pas très efficace.
Ces problèmes de carambolages peuvent ou vont-ils se produire systématiquement et perturber le fonctionnement ?

Lorsque plusieurs intervenant sont susceptibles de parler sur un même bus il peut y avoir des carambolages. Il faut utiliser/développer un protocole de communication qui soit insensible aux carambolages et qui garantisse l'intégrité des échanges.
Le protocole de communication peut être très simple.
Chaque carte est identifiée par un numéro. La carte avec le numéro le plus bas commence à questionner ses voisines. Lorsqu'elle a fini elle passe la main au numéro suivant et ainsi de suite jusqu'à la dernière.
Ou bien la carte avec le numéro le plus bas commence a publier sont état sur le bus (celle qui sont intéressées le capture au passage). Lorsqu'elle a fini la suivante prend le relais et ainsi de suite jusqu'à la dernière.
Il faut bien sur prévoir des sécurités, si une carte ne parle pas dans un temps imparti, on la déclare en panne et la suivante prend son tour.
Ou alors il faut un maître qui synchronise tout le monde.

En imaginant que je choisisse cette configuration avec des cartes MINI, il faudrait acheter également un module de conversion avec port USB pour charger le programme car il me semble que les mini ne possède pas de port USB ou il y a une autre manière de faire (sans se compliquer) ?
Les cartes NANO sont plus chères mais possèdent un port USB, qu'en penses-tu ?
Pour programmer les cartes Mini il faut effectivement un câble de téléchargement qui doit coûter une quinzaine d'euros.
A toi de faire tes comptes.
Autres avantages de la nano:
  - 2 I/O supplémentaires
  - toutes les broches sont au pas de 2,54mm alors que sur la Mini il y a des broches qui sont décalées.

Je me pose une autre question, tu dis :
Quote
le RX d'une carte sur le TX de sa voisine et ainsi de suite pour faire une espèce de daisy-chain. Sans doute pas très efficace.
Dans mon cas, une carte X a besoin d'informations provenant de son propre bloc (entrées) et des sorties d'une carte Y (autres entrées de la carte X) pour savoir ce que le bloc doit faire ou comment la carte X doit se comporter pour mettre ses sorties dans le bon état (1 ou 0). Pourquoi aurai-t-on besoin des signaux RX et TX ? Doivent-elles obligatoirement être connectées ainsi pour accepter des entrées provenant de sorties d'une autre carte (j'espère avoir été suffisamment clair) ?
C'était juste un exemple d'architecture de communication. Mais comme je l'ai dit elle n'est pas très efficace.
Il vaut mieux privilégier les architectures qui permettent à une carte d'interroger ces voisines ou alors une architecture centralisée avec une carte maître qui interroge tout le monde et qui ensuite distribue un état du système à toutes les cartes.
Ma préférence allant plutôt vers un système distribué (c'est à dire sans maître) car c'est généralement plus robuste aux pannes matérielles. Si une carte tombe en panne le reste du système peut rester fonctionnel pour autant que cela ait été pris en compte à la conception..
1558  International / Français / Re: Recherche un Wiki pour y mettre mes tutoriels en français. on: August 20, 2013, 01:40:29 am

P.-S. : Est-ce que « http://arduino.cc/fr », pourrait ajouter une section Wiki francophone à son site ?
Une section existe déjà sur le playground : http://playground.arduino.cc/French/HomePage
1559  International / Le bar / Re: Bonne affaire (matrices RGB) Ki k'en veut ? on: August 19, 2013, 02:08:21 pm
Ps pour san41 : tu peut donner le prix des frais de port "classique" st'plé smiley
Et faudrait aussi décider d'une date butoir ...

cependant concernant le financement, tu as prévu quoi ? On pourra payer par chèque ? (banque française évidemment  smiley-razz)
Faut voir avec san41, c'est lui qui gére ça smiley-wink

Donc il ne manque plus que les infos de san41 pour donner le coup d'envoi!!
1560  International / Français / Re: [Mise sur rails] Laser distance + Arduino UNO on: August 19, 2013, 11:27:28 am
La boucle 4-20mA se fait entre la sortie signal et la masse.
Donc la résistance doit être placée entre signal et masse.
La broche de masse du capteur doit être réunie à la masse de l'arduino.
La broche signal du capteur doit être réunie à une entrée analogique de l'arduino.
La résistance doit être au plus près de l'arduino.
Pages: 1 ... 102 103 [104] 105 106 ... 238