Quelles sont les valeurs des résistances actuelles dans les collecteurs de transistors d'adaptation de niveau logique et inversion ?
J'y pensais, 47 k pour la base et 12 k pour le collecteur, je vais mettre moins, certains mettent 10 k et 10 k.
Je suis allé sur archive.org mais je n'ai pas trouvé une doc complète il manque pas mal de chose.
Et la mise au point n'est pas facile car on a juste quelques messages qui apparaissent dans Settings/Logging
Ça doit être possible. À voir.
Cette fois j'ai un peu moins de 10 k, la tension a diminué mais sinon on ne peut pas dire que c'est nettement mieux.
J'ai essayé d'ajouter
Comparateur
dans les décodeurs mais le dossier decoders n'est pas modifiable pour le moment.
J'ai été dans Settings (à droite de Run), et About, ensuite :
Protocol decoder search paths:
/tmp/.mount_pulsevSghh6g/usr/share/libsigrokdecode/decoders
/__w/sigrok-build/sigrok-build/sr/share/libsigrokdecode/decoders
/usr/share/libsigrokdecode/decoders
(Note: Set environment variable SIGROKDECODE_DIR to add a custom directory)
j'ai cherché /tmp/.mount_pulsevSghh6g/usr/share/libsigrokdecode/decoders
mais je ne peux pas ajouter Comparateur dans le dossier decoders
il sûrement possible de l'ajouter mais je ne sais pas comment...
je viens de voir pour Ubuntu : .local/share/libsigrokdecode/decoders
évidemment c'est pareil.
J'ai trouvé quand même, je ne suis pas doué !
pour changer les droits
sudo chown -R ton-nom-utilisateur ~/Documents
donc ça donne ça sans chercher plus loin, sans réglages particuliers
ici en prenant les 23 premiers bits (le 24e est le signe d'après les infos sur ce protocole) du second mot on obtient la valeur 37 avec le décodeur de fdufnews
si le 23 bits de ce mot étaient à 1 le nombre serait égal à 8 388 607
37/ 8 388 607 ça fait un bon candidat pour un 'zéro physique',
En faisant une acquisition pour la plus grande mesure possible avec ce comparateur il y a sans doute moyen de trouver le coefficient de conversion en mm
Je n’exclu toujours pas que l’image donnée par l’oscillo soit déformée par l’oscillo.
Je te propose une manip pour lever le doute.
Tu utilises des sondes avec côté signal un embout grip-fil et côté masse un câble terminé par une pince crocodile.
Quel est la longueur de ce fil ?
Fait-il une boucle ?
Si tu as un point de reprise de masse proche (moins d’un cm) retire l’adaptateur grip-fil, retire le cordon de masse crocodile 
.
Tu aura accès à une fine pointe de mesure (fragile) qui surmonte un anneau métallique qui est la masse.
Recommences ta mesure : elle devrait être bien plus proche de la réalité.
Contrairement aux apparences les mesures a l’oscillo sont difficiles car souvent piegeantes.
As tu essayé de faire un relevé avec un analyseur logique ?
L’un ne remplace pas l’autre, oscillo et analyseur logique sont complémentaires.
68tjs j'utilise la prise de masse de la sonde, je ne peux pas faire plus court.
J'ai enlevé les adaptateurs grip-fil, donc directement la pointe, la masse juste à coté.
sans grip-fil
avec grip-fil
je suis d'accord que l'oscillo voit un peu de tout.
L'analyseur logique c'est le petit Scanalogic-2 avec Pulseview.
Sur Pulseview c'est assez stable les largeurs des impulsions, même si c'est un peu capacitif l'état 1 va être toujours au même niveau de tension, au niveau du seuil de l'Arduino c'est certainement différent du Scanalogic, mais est-ce gênant ?
al1fch
il faut tenir compte que les 5 premiers bits ça change en permanence, et les autres sont parfaitement stables quand le comparateur est à une valeur fixe, et que ça suit bien quand le comparateur a une nouvelle valeur différente de 0.00 mm.
C'est pour ça que j'ai tendance à penser qu'il ne faut pas tenir compte des 5 premiers, pour le premier mot de 24 bits.
Merci pour votre aide !
Oui, c'est une façon radicale de faire.
Perso j'aurai récupéré les 23 bits , puis géré le bruit dans le code si nécessaire au vu de son influence réelle sur le résultat de mesure. (ils représentent sans doute qq microns dans une mesure en mm)
Une mesure Pulseview avec 3 ensembles de signaux :
Comparateur_0mm_1Mhz_2_25-04-2025.zip (868 Bytes)
en comparant le second mot pour 0mm içi (message #127)
et là (message précédent)
j'ai l'impression que la valeur est en 'binaire complémenté à 2' (a gérer dans un entier signé dans le code)
d'où la bascule , autour du nombre zéro,
d'un nombre binaire ou tous les bits sont à zéro
à un nombre où tous les bits sont à un
(je ne tiens pas compte du bruit de la mesure , bits de poids faible faible)
Pour ces deux mesures il y a bien le même nombre de transistors entre le comparateur et le Scanalogic ?
Oui, le Scanalogic a 2 transistors pour retrouver le signal non inversé.
Je viens de faire une série de mesures, décodeur comparateur en hex, longueur de mot 24 :
0x6748
0x674E
0x6749
0x6746
0x674B
RAZ -0.00 mm (des fois c'est -0.00 mm, des fois +0.00mm mais stable)
0x6644
0x6640
0x6644
0x6641
RAZ +0.00 mm
0x662E
0x662F
0c6632
0x6635
RAZ -0.00 mm
0x6636
0x6633
comparateur +0.10 mm
0x62EA
0x62EC
+0.00 mm
0x663A
0x663A
comparateur +0.20 mm
0x5FDC
0x5FDE
+0.00 mm
0x674C
0x674C
comparateur +0.30 mm
0x5E13
0x5E11
+0.00 mm
0x6740
0x674C
comparateur +0.40 mm
0x5ABD
0x5ABB
+0.00 mm
0x674C
0x6750
comparateur +0.51 mm (pas réussi à stabiliser à 0.50 mm)
0x5778
0x577A
0x5779
+0.00 mm
0x674B
0x675D
Si on essaie de donner du sens aux valeurs, les résultats ne sont pas toujours très cohérents
La 1ère colonne c'est les valeurs que tu as collectées
La 2ème c'est les valeurs converties en décimal
La 3ème c'est la valeur - le zéro fait juste au-dessus
La 4ème c'est le nombre de pas de mesure par mm
Les colonnes suivantes présentent les mêmes informations mais en exploitant seulement 21 bits, donc le bruit est réduit mais on retrouve la même chose.
On voit que le nombre de pas de mesure par mm n'est pas constant donc:
- soit le comparateur est "bizarre". Déjà, je suis surpris de trouver environ 8000 pas par mm, mais pourquoi pas.
- soit la méthode de mesure est mal adaptée.
Je pensais que la mesure était ainsi faite
- on fait le zéro sur une surface de référence, on récupère la valeur du zéro
- on place une cale étalon, on récupère la valeur de la mesure
- retour au 1, et on utilise une cale 0.1mm plus épaisse à chaque fois.
Donc, à chaque pas 1, on devrait retrouver une valeur sensiblement la même, hors là après avoir fait le zéro, on voit que la valeur retournée est quasiment la même que celle de la mesure précédente.
Est-ce que le "zéro" ne serait pas plutôt un cumul de valeurs? et non un zéro? et du coup l'erreur que l'on observe ne serait pas en fait liée à l'accumulation des erreurs sur des mesures successives.
Merci de prendre le temps d'étudier mon cas, et ce comparateur.
Alors pour la manipulation du comparateur et pour lire avec Pulseview, l'oscillo, je le fais à la main, pas sur un marbre avec des cales etc.
et le 0 c'est quand il est sans aucun enfoncement,
des fois c'est +0.00 mm des fois -0.00 mm.
J'appuie sur le bouton de mise à 0 ça ne change pas normalement,
des fois ça peut passer de -0.00 mm à +0.00 mm,
ensuite j'appuie doucement et je stabilise à +0.10,
après je le laisse revenir à 0.00,
de nouveau j'appuie jusqu'à +0.20 et je laisse revenir à 0.00 etc.
J'ai fait aussi un petit tableau, et je constate que le 0 n'a pas toujours la même valeur, des fois des 0x66.. des fois 0x674, sans raison apparente.
Je pense aussi que ce comparateur est "bizarre", pas constant, pas comme un pied à coulisse, sauf en lecture directe sur l'afficheur, c'est sa fonction de base, il n'est pas sensé donner plus, pas comme le SHAHE avec prise mini USB.
J'ai eu une autre mauvaise idée !
J'ai fixé le comparateur avec des aimants, et une vis M3 pour pousser l'embout du comparateur, très bien pour faire des valeurs fixes mais au niveau data ça a tout changé.
Le comparateur est sensible au champ magnétique, pourtant l'affichage est resté "normal".
Sur Pulseview maintenant j'ai :
à 0 des 0x6FC, 6FD, 6F5, 6F2, 6F7, 6F3
à 0.10 des 0x3D6, 3D5, 3CB, 3CA
Je me demande s'il ne serait pas raisonnable de laisser ce comparateur de coté, en espérant que le SHAHE fonctionne bien, j'attends le connecteur mini USB.
Après avoir essayé le "vieux" comparateur il donnait toujours des valeurs un peu approximatives, pas toujours les mêmes, pas de grosses variations.
J'ai enfin reçu les prises Mini USB pour mettre sur le comparateur neuf SHAHE et là c'est parfait ! Ouf !
Le protocole est différent mais conforme au décodeur Caliper de Pulseview, ça fonctionne normalement, valeurs positives en mm, valeurs négatives, remise à 0 valeur relative, enfin comme l'afficheur.
J'ai aussi reçu un nouveau petit circuit style "Scanalogic" chinois 24MHz 8 Ch et ça change la vie, enregistrement bien plus long etc. pour environ 8.5 € c'est vraiment bien.
J'ai fait une pĥoto des fils à connecter sur la Mini USB si des fois quelqu'un cherche comment c'est fait...
IL n'y a plus qu'à reprendre le programme Arduino pour prendre en compte ce comparateur.
En plus comme il est en 3 V plus besoin de transistor pour convertir en 5 V, donc plus d'inversion des signaux etc.
12 Mhz et 10 M samples, c'est beaucoup mieux
décodeur Caliper fonctionne impeccable avec ce comparateur
Mise à jour du programme du banc de test d'arbre à cames, 2 moteurs pas à pas qui entraîne l'arbre de 1° et lecture du comparateur à chaque pas, avec un temps de pause entre chaque mesure.
Il va juste falloir ajuster avec les moteurs et engrenages, le temps de pause, la plage d'angle à parcourir en fonction de la came à mesurer.
#include <Stepper.h>
/* ========== CONSTANTES ORIGINALES ========== */
const float angleMax = 200.0;
const int cycleTime = 100;
const int stepsPerRevolution = 800;
const int stepsPerDegree = 16;
const int motorSpeed = 20;
/* ========== CONFIGURATION PINS ORIGINALE ========== */
const byte clockPin = 2;
const byte dataPin = 3;
const int boutonPin = 4;
/* ========== VARIABLES ORIGINALES ========== */
volatile long rawValue = 0;
volatile int interruptFlag = 0;
volatile int currentBit = 0;
volatile int sign = 1;
float mesureMm = 0.0;
unsigned long angleDeg = 0;
bool systemActive = false;
Stepper myStepper(stepsPerRevolution, 8, 9, 10, 11);
/* ========== FONCTIONS ORIGINALES ========== */
void processCaliperData() {
static unsigned long lastPulse = 0;
byte dataIn = digitalRead(dataPin);
unsigned long now = millis();
if((now - lastPulse) > cycleTime) {
mesureMm = (rawValue * sign) / 100.00;
currentBit = 0;
rawValue = 0;
sign = 1;
}
else if(currentBit < 16) {
if(!dataIn) rawValue |= 1 << currentBit;
else if(currentBit == 20) sign = -1;
currentBit++;
}
lastPulse = now;
}
void handleButton() {
static bool lastState = HIGH;
bool currentState = digitalRead(boutonPin);
if(currentState != lastState) {
delay(50);
if(currentState == LOW) {
systemActive = !systemActive;
if(systemActive) angleDeg = 0;
}
lastState = currentState;
}
}
/* ========== SETUP ORIGINAL ========== */
void setup() {
Serial.begin(115200);
pinMode(clockPin, INPUT);
pinMode(dataPin, INPUT);
pinMode(boutonPin, INPUT_PULLUP);
myStepper.setSpeed(motorSpeed);
attachInterrupt(digitalPinToInterrupt(clockPin), []{ interruptFlag = 1; }, RISING);
Serial.println("LABEL,Angle(°),Mesure(mm)");
}
/* ========== LOOP ORIGINAL AVEC DÉLAI CONSERVE ========== */
void loop() {
static unsigned long lastMoveTime = 0;
const int delaiMesure = 1000; // Délai original préservé
handleButton();
if(interruptFlag) {
interruptFlag = 0;
processCaliperData();
}
if(systemActive && angleDeg < angleMax) {
if(millis() - lastMoveTime >= delaiMesure) {
myStepper.step(stepsPerDegree);
angleDeg++;
lastMoveTime = millis();
Serial.print("DATA,");
Serial.print(angleDeg);
Serial.print(",");
Serial.println(mesureMm, 2);
}
}
}
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.