Show Posts
Pages: 1 ... 40 41 [42] 43 44 ... 87
616  International / Français / Re: lire puis reproduire un code série on: August 15, 2013, 02:43:23 am
Je n'ai pas regardé la forme du signal sur la LED émettrice de la clé, mais en sortie du récepteur IR, on est sur un collecteur ouvert, la pul-up est fournie par le boîtier-décodeur (+5 ou +12, ça n'a pas d'importance dans notre cas), on peut donc sans souci remplacer le récepteur IR par un simple transistor NPN. Pour ce qui est du signal en sortie du récepteur (et donc en entrée du décodeur), il est à 1 en IDLE, et propose un train d'impulsions à 0 toutes de la même durée. Reste donc à voir si sur la LED j'ai exactement le même signal. donc si c'est seulement un problème de réception (cellules fatiguées par exemple), à partir du schéma d'origine :

clé(LED) => (cellule IR)récepteur(collecteur ouvert) -> (pullup)décodeur -> calculateur d'injection

on peut imaginer le schéma suivant :

clé(collecteur ouvert) -> (pullup)décodeur -> calculateur d'injection
ou
clé(NPN) -> récepteur(collecteur ouvert) -> (pullup)décodeur -> calculateur d'injection (si le signal de la clé n'est pas le même électriquement)

ou encore :

arduino -> calculateur d'injection

légende :
=> liaison IR
-> liaison filaire
(xx)yy(zz) module yy avec format d'entrée xx et de sortie zz

la première solution me plait beaucoup mieux, car avec un simple émetteur RF à deux boutons, je peux déclencher la clé (pour l'ouverture) et le bouton FC (pour la fermeture). Et il y aura un bouton poussoir pour la manip manuelle, car chez nous, les clés restent sur le contact la nuit (voiture donc ouverte), donc pour démarrer le matin, il faut un système de déverrouillage simple. Bref, dans ce cas, pas besoin d'arduino.

Pour la seconde, il faudrait pirater le code généré par le décodeur et réussir à le générer...

Ce qui m'impressionne, c'est que dans le code tournant, ils ont prévu le cas où un (des) codes s'évaporeraient dans la nature...

depuis que j'ai découvert arduino et que les premiers calculateurs d'injection étaient à base de 68HC11 à 8Mz, j'y pense, à faire mon propre calculateur (cartographies reprogrammables à souhait via USB...). Mais ça, c'est pas pour tout de suite. Mais j'ai déjà tout ce qu'il faut pour relever les cartographies injection et allumage des calculateurs, il suffit de simuler les signaux des capteurs du moteur, et il n'y en a pas tant que ça de vraiment utiles au calcul.
617  International / Le bar / Re: MINITEL MAGIS DEBUT D'INVESTIGATION on: August 14, 2013, 01:22:54 pm
Si si sans doute, mais ça ressemble à du ethernet, ça doit être un truc style rj9 ou quoi.
si tu regarde bien, tu as la même sur ta box internet, et c'est du RJ11 pour se connecter sur le réseau commuté PTT : la ligne téléphonique... Il faut que tu lises bien les docs, FT n'est pas avare de ce côté. tu aurais du attendre avant de le démonter...

Sinon, tu trouveras dedans un endroit où raccorder quelques fils pour rajouter une prise péritel. Moi, ça m'a permis de voir que mon vieux minitel première génération gérait en natif la couleur...
618  International / Français / Re: lire puis reproduire un code série on: August 13, 2013, 02:48:42 pm
Surtout que les connaissant, je vais tomber sur un série classique 62500 voire même 115200... mais faut quand même tomber sur le bon, et comme c'est la voiture à madame, ben ça va pas être facile, elle bouge tout le temps... je lui ai proposé de prendre ma R21 de 1996 qui marche bien (pas d'antidémarrage), mais elle préfère la sienne... ah les femmes...
619  International / Français / Re: lire puis reproduire un code série on: August 13, 2013, 01:39:50 pm
Justement, c'est bien ça que je veux faire. A la mise du contact, au bout de 1 seconde, j'envoie le code à l'ecu. Je peux lire ce code, puisque j'ai la manip de secours (là, il faut être synchro pour enregistrer la séquence...). Et le faire plusieurs fois pour être sûr que c'est tout le temps le même, ou voir s'il change...
620  International / Français / Re: lire puis reproduire un code série on: August 13, 2013, 09:26:50 am
Quand je dis aux gens que Renault c'est la pire daube ...

(désolé pour toi Super_Cinci)
d'accord avec toi, mais seulement à partir de 96/97, quand les normes sont apparues. jusque là tout allait bien (tout était accessible, et je sais de quoi je parle). Maintenant, c'est tellement pourri d'électronique que même si la méca reste fiable, on est toujours emm....

@ neodelavega, si seulement c'était le commun des injecteurs qui était coupé, ce serait trop facile. comme c'est un µP qui gère les commandes d'injection, il serait étonnant que l'interdiction ne se fasse pas dans le code (programme) lui-même, il suffit de ne pas configurer les timers correspondants tant qu'on n'a pas reçu le code de déblocage. Ainsi, on peut déclencher toutes les fonctions et registres que l'on veut, si le timer n'est pas initialisé, il ne fera rien... Mais tu as raison dans un sens, ça ne va pas coûter grand chose de vérifier...

Je suis dans le cas du code de secours dont tu parles au 2 de ton édit, ça marche, mais c'est relou. c'est d'ailleurs par ce code de secours que l'on fait la manip de resynchronisation clé(s) / décodeur. j'ai fait une fois cette manip et ça a marché il y a deux ans. mais ça ne veut plus aujourd'hui.

pour revenir au code "évolutif", celui que la clé envoie a aussi une autre particularité, c'est que (selon les docs) on peut appuyer jusqu'à 999 fois dans le vide et le code suivant sera reconnu par le décodeur comme si de rien n'était. il y a donc une loi d'évolution de code assez tordue donc difficile à trouver, même si on peut en lire plusieurs d’affilé, on ne trouvera pas cette loi tout de suite... pour info, les signaux que j'ai pu relever à l'oscillo, c'est une 10aine d'impulsions, soit une 20aine de bits. comment faire un code aussi précis avec seulement 20 bits?

il me reste une solution, ce serait de remplacer la led IR de la clé par un bon vieux NPN, et remplacer le récepteur IR par le collecteur de ce NPN. là, plus de parasites, on passe en direct, et si le code ne veut pas passer, alors oui, renault a tout fait pour qu'on jette la voiture au bout de 15 ans (son âge)...
621  International / Français / [résolu] lire puis reproduire un code série on: August 12, 2013, 04:00:46 pm
Bon, c'est simple, j'ai la voiture de madame qui foire, c'est du renault 2000, c-à-d que c'est plein d'électronique et donc plein d'emmerdes.

l'émetteur de la clé est en IR avec un "code évolutif", code reçu par un décodeur qui envoie un autre code aussi évolutif au calculateur d'injection pour déverrouiller l'anti-démarrage (le calculateur refuse d'injecter de l'essence s'il ne reçoit pas le bon code).

et le code IR ne marche plus. n'allez pas m'embrouiller avec la méthode de resynchronisation clé / calculo, je la connais par coeur, et elle ne marche plus. j'ai passé l'oscillo en sortie du récepteur, la clé marche impec. là, c'est un problème Renault : trop d'électronique tue l'électronique. coût de la remise en marche chez renault : entre 300 et 600€.

comme j'ai des doutes sur le récepteur IR (présence de parasites en sortie), je pense à passer avec une télécommande RF à base de PT2262 / PT2272, c'est pas cher et fiable.

Mais il faut qu'un petit ATMEL envoie un code au calculateur pour lui dire de déverrouiller l'injection. je peux relever le code avec l'ICP1, mais comment trouver la loi évolutive (un code différent à chaque coup, et pourtant le calculateur le reconnait...) qui me permettra de générer un bon code à chaque coup...?

si l'un d'entre vous connait ça, je suis preneur!
622  International / Réalisations et Projets Finis / Re: Une fonction de micro-hybridation de voiture on: August 12, 2013, 03:29:53 pm
Je te donne un peu de lecture, mais toutes mes idées y sont : http://forum.arduino.cc/index.php?topic=119201.0, voir côté dernières pages, car on passe de la R11 carbu à la R21 injection multipoint... mais l'objectif reste le même, les Renault de l'époque étaient toutes construites pareil.

En gros, pour intégrer la gestion de l'alternateur, j'ai comme info :
- la vitesse de rotation moteur,
- la dépression dans l'admission,
- la position accélérateur,
- tension batterie,
- rapport boîte,
- pédale frein,
- pédale embrayage,
- durée d'injection,
- avance allumage,
- mode régulation ou limiteur de vitesse (là, utile pour freiner un peu si on va trop vite),
- et encore plein d'autres!

par contre, je pense que je me contenterai de couper l'alimentation de l'alternateur, car gérer une sortie PWM de plus avec toute la régulation qui va autour, ça va devenir chaud...
623  International / Réalisations et Projets Finis / Re: Utilitaire windows de visualition de trame on: August 12, 2013, 06:10:00 am
Ce genre d'appli fait partie de ce que je dois développer, car je travaille surtout avec des byte sur port série, et c'est toujours pratique d'avoir un terminal qui ne fait pas que du texte! Je n'ai pas regardé ton projet, mais si tu en parles, c'est qu'il te convient, et doit convenir à d'autres!

Bonnes continuations!
624  International / Réalisations et Projets Finis / Re: Une fonction de micro-hybridation de voiture on: August 12, 2013, 06:05:27 am
Ca, c'est une idée qui me plait.

En effet, soulager le moteur pendant les phases critiques (ralenti, accélérations...). J'imagine que du coup, ça doit faire du bien à la batterie en la faisant travailler un peu plus.

Je crois que je vais intégrer ça dans mon projet de TDB numérisé, puisque j'aurai déjà toutes les données nécessaires, comme la dépression d'admission qui reflète bien la charge du moteur ou le frein moteur...

Merci d'en avoir parlé!
625  International / Le bar / Re: Calcul de distance, HELP ! on: August 12, 2013, 05:40:56 am
Mais il faudra que tu puisses aussi mesurer la distance de la cible...

Est-ce qu'une première version qui balance un jet horizontal dans un premier temps irait (une seule dimension)? au besoin, tu peux balancer le jet et monter un peu pour arroser sur une distance plus longue?
626  International / Français / Re: Stabilité des mesures en fonction de l'alim ?!! on: August 12, 2013, 02:47:01 am
Il ne faut pas mélanger précision et bruit.
non, je ne confonds pas, j'y ai déjà pensé...
L'utilisation du Vcc comme alimentation et tout sauf précis mais dans le cas ou on utilise des capteurs potentiomètriques si cette même tension est utilisée pour polariser les capteurs alors l'erreur s'annule. Par contre l'alimentation est bruitée.
Je dirais plus que l'alimentation est loin d'être optimisée, car le 5V de l'usb passe par un switch, et ce switch a une impédance assez gênante. reste qu'on y gagne beaucoup en alimentant directement en 5V depuis une bonne alim!
Ensuite il y a le problème de conception de la carte arduino. Le Aref se ballade sur la carte et il attrape tout ce qui passe. Moralité le problème de bruit sur la référence et plus dû à cette piste mal routée qu'à la qualité de la référence.
tout-à-fait d'accord!
Concernant l'utilisation d'une référence externe. Dans la documentation Atmel il est dit que la sortie Vref (la référence interne) est une source haute impédance. Donc elle ne mettra pas ta référence en court-circuit. Mais ce sera plutôt l'inverse. Si toi de ton coté tu prends la précaution de ne pas sortir sur une impédance trop basse (prévoir une résistance série dans la connexion vers Aref) alors il n'y aura pas de court-circuit. Par contre tant que le choix de la source de la référence n'aura pas été fait par le soft les résultats retournés par l'ADC seront faux.
j'avais remarqué un pic d'intensité sur mon alim (j'avais collé une zener sur Aref), d'où mon doute...
Ce que je disais, c'est que la référence par défaut étant le VCC qui bouge beaucoup, chaque conversion est faite avec une réf différente, donc résultat différent (exemple de mesure d'une simple pile : on n'aura pas souvent deux fois la même valeur...). Mais pour avoir imposé une ref externe, j'ai grandement amélioré la précision!
Et dans tous les cas, comme il a été dit plus haut ajouter un condensateur sur la pin Aref du processeur.
ça ne fera jamais de mal smiley-wink
Il faut aussi noter que chez Atmel  il n'y a pas que des idiots et ils ont prévu un mode réduction du bruit pour les acquisition par l'ADC qui utilise la mise en veille du processeur pendant les conversions afin de réduire les perturbations. Mais là il faut écrire sa propre fonction analogRead.
mais en même temps, ça ne change rien dans le fonctionnement, car analogRead bloque le processeur le temps de la conversion (mais n'empêche pas les interruptions je crois)
627  International / Réalisations et Projets Finis / Re: Détecter le contact de broches numériques entre elles on: August 12, 2013, 01:02:03 am
Heu...

est-ce que tu essaies de fabriquer un makey? dans ce cas, ton code serait simplement :

Code:
byte result;  // variable contenant la lecture

void setup(){
  DDRD &= 0x83;  // pins D6:2 en entrée
  PORTD |= 0x7C;  // activer les pull-up
}

void loop(){
  result = (!PIND & 0x7C) >> 2;  // lecture et conversion du port D, 1 pour ce qui est "touché".

// ici l'utilisation de result.

}

reste à voir si les pull-up ne sont pas trop faibles pour détecter le corps humain, dans ce cas, on peut utiliser des résistances externes de 220K à la place de celles de l'arduino qui sont de l'ordre de 10K je crois.
628  International / Le bar / Re: Calcul de distance, HELP ! on: August 12, 2013, 12:46:09 am
Moi, j'aurais fait plus simple (la mécaflu, c'était pas trop mon truc). J'aurais fait 3 ou 4 mesures (pression, diamètre tube, distance), appliqué à une parabole et zou, on trouve une certaine relation entre les données, on en tire une petite formule assez simple, et basta.

Ensuite, on s'aperçoit que ça marche pas, on reprend tout à 0 et on appelle B@tto.

(ok, je sors...)
629  International / Français / Re: Stabilité des mesures en fonction de l'alim ?!! on: August 12, 2013, 12:36:26 am
Oui, je me répète un peu, alors je tente un résumé...

Sur un montage, j'ai eu ce souci de valeurs analogiques qui bougent toutes seules. j'y ai remédié en utilisant une tension de ref sur Aref. j'utilise alors cette tension Aref comme source pour mes potars ou capteurs. mais le souci, c'est que la pin du Aref du µP est directement reliée à la référence de l'ADC, soit AVcc au reset. Comme AVcc = Vcc, si on met une zener de 4.7V, il va y avoir pas mal de courant à passer par là tant qu'on ne fait pas un changement de référence Aref, au risque de détruire une partie du composant. je ne vois pas trop comment résoudre ça, mais une fois la référence externe en place, ça ne bouge plus du tout. utiliser un relais qui commuterait une bonne tension de référence une fois Aref déconnecté (par software) de AVCC?

Pour avoir branché un oscilloscope sur le Aref de la carte, je vous confirme que ça bouge dans tous les sens sur près de 200mV, en gros, pour s'en affranchir, il faudrait faire mesure = analogRead(xx) >> 3, soit faire retomber la précision à 7 bits (0 à 127 au lieu du 0 à 1023 d'origine)...
630  International / Français / Re: [Projet] Un tableau de bord numérisé on: August 11, 2013, 12:59:08 pm
Effectivement, pour l'instant, j'ai fait mes premières brides de code avec PSPad, un éditeur miltulangage (très pratique en PHP qui propose une coloration syntaxique bien plus claire qu'arduino, et qui a l'avantage de lister toutes les fonctions et #define d'un fichier pour se retrouver et naviguer plus vite. On peut lui associer un (des) compilateur(s), il faudrait essayer.

sinon, j'ai monté une platine avec une dizaine de potars et 24 inters, une alim 12V + 5V, et en plus un UNO qui génère la trame "XR25" (trame série du calculateur d'injection) avec de nombreuses données qui bougent (vitesse moteur, durée d'injection, avance allumage, dépression admission...), et quelques signaux d'impulsions (vitesse véhicule, débitmètre...). J'ai donc un banc d'essai (complet?) pour le développement sur le 2560, car ce n'est pas facile de développer un truc en conduisant.
Pages: 1 ... 40 41 [42] 43 44 ... 87